Still trying to get good.

The requirements are forever shifting, and so do the applied paradigms.

I think the first layer is learning about each paradigm.

You learn 5-10 languages/technologies, get a feeling for procedural/functional/OOP programming. You mess around with some electronics engineering, write a bit of assembly. You write an ugly GTK program, an Android todo app, check how OpenGL works. You learn about relational models, about graph databases, time series storage and key value caches. You learn about networking and protocols. You void the warranty of all the devices in your house at some point. You develop preferences for languages and systems. For certain periods of time, you even become an insufferable fanboy who claims that all databases should be replaced by MongoDB, or all applications should be written in C# -- no exceptions in your mind are possible, because you found the Perfect Thing. Temporarily.

Eventually, you get to the second layer: Instead of being a champion for a single cause, you start to see patterns of applicability.

You might have grown to prefer serverless microservice architectures driven by pub/sub event busses, but realize that some MVC framework is probably more suitable for a 5-employee company. You realize that development is not just about picking the best language and best architecture -- It's about pros and cons for every situation. You start to value consistency over hard rules. You realize that even respected books about computer science can sometimes contain lies -- or represent solutions which are only applicable to "spherical cows in a vacuum".

Then you get to the third layer: Which is about orchestrating migrations between paradigms without creating a bigger mess.

Your company started with a tiny MVC webshop written in PHP. There are now 300 employees and a few million lines of code, the framework more often gets in the way than it helps, the database is terribly strained. Big rewrite? Gradual refactor? Introduce new languages within the company or stick with what people know? Educate people about paradigms which might be more suitable, but which will feel unfamiliar? What leads to a better product, someone who is experienced with PHP, or someone just learning to use Typescript?

All that theoretical knowledge about superior paradigms won't help you now -- No clean slates! You have to build a skyscraper city to replace a swamp village while keeping the economy running, together with builders who have no clue what concrete even looks like. You might think "I'll throw my superior engineering against this, no harm done if it doesn't stick", but 9 out of 10 times that will just end in a mix of concrete rubble, corpses and mud.

I think I'm somewhere between 2 and 3.

I think I have most of the important knowledge about a wide array of languages, technologies and architectures.

I think I know how to come to a conclusion about what to use in which scenario -- most of the time.

But dealing with a giant legacy mess, transforming things into something better, without creating an ugly amalgamation of old and new systems blended together into an even bigger abomination? Nah, I don't think I'm fully there yet.

  • 3
    Wow. Seems exactly what i would want to do. Couple of questions.
    1. How long have you been programming?
    2. How do you or rather how did you avoid getting overwhelmed?
  • 3
    I agree man. I'm kinda at the same place although I admit I'm way closer to 2 than 3, I still have the idealistic perspective that things will work out simply because a certain kind of process is followed which is shown to be more stable. I'm slowly breaking out of that as I get more experience, modifying existing processes based on logical assumptions of what will be more stable and what won't.

    Though I do wonder, is there a fourth layer? What would that look like? After you've conquered city building, will it be trying to conquer space -- building systems or processes of thought/code yourself?
  • 2
    Hot damn. Very well written.

    It's an evolution of your decisions slowly affecting more people. I'm still trying to get into the third layer myself. And it probably has been the most nerve-wracking thing ever. This time experiments have long-term impacts and that's the reason why probably it's a lengthy process.
  • 5

    Hobby since '88, semi-professional since... 91-92 or so I think? I started by making small batches of game cartridges for the Commodore 64.

    I don't avoid getting overwhelmed, once every while I bring 20 sticks of butter to the office, get naked, and challenge everyone who has wronged me to a wrestling match.
  • 2
    It's uncanny how relatable this is. Great write. I feel like I've just recently reached L2, while still having a few things in L1 (still tinkering with stuff I barely know enough about, just because I know there's much more for me to know about how things work and how to make them work together much better). Reaching L3 is probably the biggest process of them all, so I'm glad I've still got most of my life ahead of me
  • 1
    there are useful patterns for legacy refactorings too. It`s nothing new. Developers have been refactoring systems for years now. Look up "strangler pattern" and the term "anti-corruption layer". Disclaimer: It`s not easy and Microsoft, Google etc. are fighting these kinds of problems day to day. Game engines have to fight this issue on a regular basis as well.

    Further reading:



    EDIT: I realize this wasn`t op`s point, might be of interest to the common passerby nonetheless.
  • 0

    I agree that strangling has advantages over fully rewriting.

    The issue is that the "eliminate" phase of the strangler pattern is extremely difficult to get done: Even when you successfully move a service out of your monolith, you're still stuck with adapters in the monolith to make it successfully communicate with the spaghetti.

    Engineers now have to deal with even more paradigms.

    Then there's always the Complicated InfrequentlyUsedHighlyCoupledService — something which will take a few weeks to decouple into a nice separately deployable service, but management will never allow for that time allocation.

    They won't see the weight of the technical debt of maintaining two paradigms, they only see a "that service is currently working fine and doesn't need a feature change, it can stay in the monolith"

    The issue with incremental replacement is that some systems will never be visited, so you'll end up with an amalgamation of legacy+modern — which is arguably worse than a unified legacy system.

    We had a similar issue with something simpler than microservice backends: CSS frameworks. First there was bootstrap. People hated it, so the idea was to replace it incrementally with every new/rewritten feature. People hated the replacement, so another alternative was chosen. Managers only visit & revisit popular places on the website for tweaks & rewrites — so now we have three CSS systems.
  • 0
    @bittersweet that does sound awful. I'd scrap CSS and go pure HTML at this point until management starts taking you seriously lmao.
Add Comment