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?
Top comments (18)
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.
I will be graduating school after few months. I have decided not to join a college immediately after it. I'm planning to stay put for one year to have my life in order and decide career options. This is something I changed my mind about recently.
What do y'all think? Good decision?
In my experience, when people take a break it's really hard for them to go back to studying/learning/working, I recommend that you get a job or something so you don't loose the habit of working, that's what I have seen, maybe your case is different
So much this. After high school, I joined the army (to get the college benefits). When I got to college three years later, it was really hard to get back into the swing of academic life.
Go to college. You don't have to know what you're going to do right away -- try different things. Or as they say, "fuck around and find out." You can knock out a bunch of general ed class requirements while figuring out what you want to do for a living.
Yeah I can relate to what you are saying. I'll keep working on projects to not get diverted 🙋🏻♂️
Might as well get your gen-eds out of the way while you're deciding IMHO. When I was in college a few years ago, they said 80% of students change their major or minor during college, so it's not super important that you know exactly what you want to do with your whole life before you get there, and if you're trying to decide, it's helpful to have professors around to talk to who've had careers in a variety of industries and fields of study.
Also, be sure to check all your scholarships--a friend of mine in high school was an LDS, so he had to take two years off, and he ended up losing most of his scholarship money because it was earmarked for graduating seniors starting college immediately.
Just my two cents.
Yes. Take your time and get it right, there's no rush. 👍
NoSQL was such a pressure-cooker when it was hyped. It was a real relief for me when I settled into a mindset of "Okay, there is definitely a place for this technology, but I am so cool not adopting this."
I think the way the MEAN stack was marketed towards bootcamps and junior developers was a really bad thing for the ecosystem. It really was marketing too. Where were all the PEAN stack advocates. Somehow if you were in the full-stack JS ecosystem you also got shoved into NoSQL.
As for my own answer — hard to articulate, but I'd say I've changed my mind about any project management approach being inherently good or bad, and I just focus a lot more on the tweaks to get the right fit for the team and the tasks at hand. That's sort of vague, but I used to take harder stances from time to time which I just can't see myself doing anymore.
As a former PM, I've got agree with you re: methodologies. It's unfortunate that there are a lot of places that force everything into a single methodology, when in reality, each project should demand a certain methodology. When you've got a vague scope doc, unrealistic promises from sales, and high turnover in your dev team, clearly traditional waterfall methods are the way to go, right? (I'm not specifically calling out any one agency here, but I am definitely thinking of one in particular.)
I switched to PM after about three years as a dev, so I didn't learn the lesson until after I became a PM, but the thing that devs should be aware of is to never have strong opinions on approaches to solving a problem. There is no one-size-fits-all-solution and there's more than one way to skin a cat.
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.
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.
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.
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.
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.
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.
I used to overestimated technological progress, I think I might have switched to underestimate it... (or not... :-D )