One of the strongest heuristics for career progress (and personal growth) is how readily you change your mind about things. After all, everybody's wrong sometimes. If you don't change your mind now and then, you just keep on being wrong.
This is a skill that's particularly relevant to developers; we're wrong all the time. When we troubleshoot a tricky bug, we start with a hypothesis ("I think the problem is X"). Then we find evidence to disprove the hypothesis, discard it, and come up with another one. This can happen tens or even hundreds of times before we find the right fix. My favorite developers to work with can turn on a dime: "whoops, I was wrong. Let's try something else." No embarrassment, no ego, no excuses. They're interested in finding the facts, no matter how many times they have to be wrong in the process.
We should apply that mindset not just to the nuts and bolts of programming but to the ideas and beliefs that drive our careers. So tell me:
- Did you have a strong opinion as a junior developer that you've changed your stance on?
- Have you come to disagree with a blog post or DEV article that you wrote years ago?
Virtual high-five! You're less wrong than you were. Let's hear about it.
For my part, there are two things that come to mind.
NoSQL
The first time I had to write SQL, I immediately disliked it. SQL wasn't at all like the imperative code I was used to writing. Why was it so abstract and set-oriented? Why wasn't I supposed to use for loops? Why were we writing magic SQL strings instead of querying databases with a strongly-typed API?
It's not hard to find SQL haters online. At first brush, it seems to go against everything programmers are taught. So I joined the crowd, settled on "SQL is the worst possible thing," and went off to build a side project with MongoDB. I was sure it would be a slam dunk.
A few months later, I looked over my half-baked side project and had a difficult realization: I'd spent an embarrassing amount of time trying to make MongoDB do things that SQL does out of the box—schemas, normalization, relational data, auto-incrementing primary keys, and so on. SQL would have been the right technology for my project (and I now believe it's right for most projects) but I'd failed to look beyond the first impression.
Since that experience, I no longer shy away from SQL. Sure, it has its tradeoffs, and NoSQL databases are great for some situations. But most of the time SQL is safer and more reliable. Persistent data storage has a different set of problems from application code, and SQL is pretty darned good at it.
Anyone can code
I've been programming since I was a kid. It's been interesting to me—nay, captivating—since the first moment I knew what it was. Even when my long-term plan was to go to law school and become a politician, I was spending my free time playing with jQuery and reading CSS-Tricks.
That means when I got my first programming job, I'd already been writing code for about a decade. That's a big advantage. Algorithmic thinking was second nature to me, and more importantly, I had a reliable sense of what programming languages could and couldn't do, so I knew what to Google and what to write by hand. Some things were still difficult to learn (async and Promises took me forever to figure out) but for the most part, things came easily, and the chaos of mid-2010s JavaScript was more exciting than intimidating.
The mistake I made was projecting my experience onto everyone else. "Code is simple and makes sense," I thought. "Surely everyone can learn if they put in the time."
I was wrong about that. A handful of years in the industry has taught me that everyone is different. Sure, a lot of people can learn to code. But a lot of people can't, or at least not to the level of a marketable skill. Everybody's smart at something; that something usually isn't code. And even among the people who can learn to code, many of them wouldn't enjoy the solitary and repetitive nature of a programming job. I've left team anybody can code and joined team try it out first, see if you like it. This has helped me make far better recommendations to people who ask me about a career in tech.
Your turn. What have you changed your mind about lately?
Latest comments (18)
Nice post cover 😄
I changed my mind about writing perfectly clean and fast code. Everything is a tradeoff.
Just in time compilation and garbage collection. Back in the late 90s/early 2000s when I felt like a C++ expert and computers will still slow enough that performance in everyday code mattered, I thought it was an anathema to waste all those resources on memory graph scans, interpreting bytecode and compiling on the fly. I couldn't have been more wrong. Managed memory and JIT-compiled code is today often better performing than precompiled native machine code.
Too many things over the years. Being comfortable changing your mind shows (I think) that you welcome other ideas and suggestions and that you listen and take them on board.
I used to consider that Back-end was "the real staff" while web development (front-end) was the easy thing. I struggled to get the master degree and I used to think in these terms of "I've studied to do back-end things, i should do this" .
I've been gradually changing to pure front-end development for the last years.
I'm happier now.
I used to overestimated technological progress, I think I might have switched to underestimate it... (or not... :-D )
Thanks for your post, especially your examples which I found funny compared to my own change of mind.
When I first heard about noSQL I found it terribly wrong, just like I did when I first heard about using JavaScript in the backend, and just like I did when I ... started to use SQL!
So long ago that I forgot in the meantime, but there have been many technologies that I later came to embrace and even love, or at least dispise less. In the end, they are nothing but tools anyway to make some electronic devices to some arcane process to produce some useful output.
I even remember writing a parody about SQL for its unintuitive behavior of NULL, calling it the "NON language" where everything that ever has the slightest contact with "NON" turns itself into "NON". Later, I got to like SQL for its compact syntax that can fit a lot of complex logic into a single line of code.
I also remember being quite skeptical about computers and programming when my cousin first showed me some code and its disappointing output. We were both kids back then.
Funnily, opinions can go on a round-trip much like major technological trends. Assembly machine language vs. high level human readable languages (or even prompts to a chatbot that would write the actual code), separation of content and style vs. the comeback of functional CSS class names in Tailwind CSS (that never went away, see Bootstrap) which, of course, reminds me of the hard time changing all of my
<font color=red>to<span class="red">to<span class='site__article--main-article'>to ... (and so on) over the years.I used to be very skeptical about Windows, or graphical point-and-click interfaces in general (everything used to be so quick and simple just keeping my 10 fingers perfectly positioned above my mechanical keyboard?), same with CSS (why would we want to move markup away from where it's going to be applied?). Now I use a lot of the tools together or when they seem to fit, still typing on a mechanical keyboard most of the time, using the
vieditor forgitand configuration files, but a complex IDE for coding, and web browsers with their developer tools which are hard to imagine without a graphical context.I remember a few technical tools that I liked from the start and still do, including Linux, HTML, and the GIMP.
Concerning people, we can be wrong about others, we can change our mind, and we should. There is love at first sight, there are deceptive characters, impostors, or people getting corrupted by power, money, or grief. On the other hand, as you mentioned junior developers, some people have a weak start or a bad day but make up for that in the long run. So I would never judge anybody based on the first impression either.
I thought the main issue of monolithic solutions was composability and that I could solve it, but it turned out the real issue was complexity. I learned that it's better to have simple primitives which work in any context than a complex solution that does that all only in its own context.
I had written a monolithic fetch module for solid-js, aimed at bridging the gap between createResource and tanstack query, but the composability was the second biggest part after caching. The complexity was a foot-gun, so only few people used it.
So I started breaking it up into case-agnostic primitives that can be used for more than just fetch and leave the composition to the developer.
In my language we speak: measure seven times cut once. It's important planning your actions or algorithms and develop but not both or reverse order in same time.
For me it was the individual contributor vs management track. Previously I was adamant that I wanted to stay as a developer, be one with the code and spend my days designing elegant solutions to complex problems. However, more recently I've noticed the positive changes that a good engineering manager can have and I've now retracted that opinion and am more open to the idea of becoming a manager.