Things I’ve learned in my years as a software engineer (2021)

Nice post! As a software dev of more than twenty years myself I nodded along with most of this list.<p>I disagree about the value of opinions. They’re generally bad, often wrong, and don’t solve anything. Have them, sure, but keep them to yourself unless asked. We like to think our opinions are reasonable, well researched, and unbiased but nothing is further from the truth.<p>Be open to changing your mind, let evidence and results guide you, always be open to learning new things! Opinions change with what you know so don’t hold on to them.<p>For me the biggest difference between a senior engineer and a junior engineer is experience. The former knows enough about the state of the art in their area of the field that they can train other people in what they know. Those people that they train go on to become senior engineers themselves.<p>One thing I’d add: if you’re a software developer, think about your principles. What maxims and rules guide your thinking? What do you value? I encourage writing those down and re-writing it every few years to see what has changed. Maybe one day you’ll be writing a list like this.

&gt; We should be far more focused on avoiding 0.1x programmers than finding 10x programmers ... The 10x programmer is a silly myth.<p>I&#x27;ve worked with far too many 0.1x programmers, too many 1x programmers to count and maybe a handful of 10x programmers.<p>I always flabbergasted when people say things like &quot;The 10x programmer is a silly myth.&quot; ... have they really, in all their years, never, ever worked with a superstar?<p>I worked with a guy who wrote the framework of a medical imaging system almost entirely by himself; hundreds of thousands of lines of FDA design systems quality code complete with tests that formed the backend of a successful product that was used on almost every MRI and CT scanner for years all while mentoring developers all around him.

&gt; Your data is the most important part of your system<p>This is true in pure code as well.<p>In coding, I believe there is a hierarchy, from most important to least important: data structures, algorithms, documentation&#x2F;comments (not an original idea)<p>That&#x27;s because if you change your data structures, your algorithms and documentation will break, you can change the algorithms while keeping your data structures, but it will break documentation, and changing the documentation will affect neither the algorithms nor data structures. So spend the most effort getting your data structures right, then the algorithms, then your documentation.<p>On a higher level, generally, data is useful by itself, code is only useful if it has good data to process, and documentation is only useful if it documents working code. Same idea.

&gt; Nothing worries me more than a senior engineer that has no opinion of their tools or how to approach building software. I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all. If you are using your tools, and you don’t love or hate them in a myriad of ways, you need to experience more<p>Strong disagree. If you haven&#x27;t found an issue with something you love, or a useful aspect in something you hate, you need to experience more. I don&#x27;t know if I&#x27;m senior other than doing this for a while, but I had more opinions when I was starting out than now. I do have more clear opinions now in terms of being able to say why something is important. But a great number of things (statement vague on purpose) people have strong opinions about are not really important.

I have the feeling that code is becoming less and less important. In my day to day job as a SWE, coding is the easy part. There are tons of other things to do besides coding, service maintenance, discussing priorities and trade-off, helping users, fixing perf issues, code review, oncalls, tweaking configurations, understanding poorly-documented API and other systems.<p>Maybe I&#x27;m getting old, but it seems there are more and more things to know. Sometimes it&#x27;s overwhelming and the constant context switching is killing me.

This is one of the best pieces of advice in the article:<p>&gt; You learn so much as you’re building a system that you will end up iterating into a much better system than you ever could have designed in the first place. This is surprisingly a hard sell to most people.<p>And it&#x27;s one I wish I&#x27;d kept in mind for a lot of personal projects in my life. I love designing stuff up front and implementing things based on that, but often that&#x27;s led to sticking with ideas that didn&#x27;t actually pan out the way I expected them to, especially when it comes to game design&#x2F;development. A lot of the time, a good level or game or boss fight or whatever is completely different to what you initially imagined it would be, and you should be willing to change direction to fit the bill.<p>&gt; Sometimes you have to stop sharpening the saw, and just start cutting shit<p>Also this one for much the same reason. Overplanning for things is a curse, especially when said plan hasn&#x27;t quite come into contact with reality.

This section:<p>&gt; 4. The best code is no code, or code you don’t have to maintain<p>Relativised in the last sentence:<p>&gt; This is a balancing act, there are lots of reasons to grow your own, but beware of toxic “Not Invented Here” syndrome.<p>Rubs me the wrong way. I get what he is saying here. But damn this feels outdated to me coming from web development.<p>I work in a small web dev team, but we&#x27;re constantly working hard to reduce dependencies and rather code things up ourselves. We have designed it, we know how it works, what it can do and what it can&#x27;t. We have tested it, we maintain it. It is smaller and more purposeful and fits our needs well.<p>Just keep in mind that this is a learning process.<p>You will likely suck at writing your own libraries and tools until you made some mistakes. But the end result is code that does exactly what it needs to instead of something that is cobbled together, hard to debug, hard to change.<p>When your code breaks you can debug the code in your head, while you are walking your dog or after you woke up from a nap. You can see it all there, you can _feel_ it.<p>With external tools, services and libraries it&#x27;s not like that. It&#x27;s always a black box. And it might suddenly change its contents if you look at it funny.

&gt; Nothing worries me more than a senior engineer that has no opinion of their tools or how to approach building software..... You need to explore other languages, libraries, and paradigms.<p>Funny. I&#x27;ve used a wide range of things in my career and if anything, it&#x27;s made me less opinionated, not more. There&#x27;s something that sucks about everything, and usually the part that sucks is slightly different, so... why should I be so opinionated about what I&#x27;m using? It all sucks in slightly different ways anyways.

Sharks also <i>evolve</i>. There were sharks 400M years ago, but they weren&#x27;t the sharks of today. Some core banking app written in the 70s and still running today on a mainframe that requires software and hardware emulation of a 1970s mainframe is probably a dinosaur.<p>Something like unix that sprang up in the 70s on the same types of mainframes and has evolved and changed a lot over time but still kept a lot of core conceptual DNA is probably a shark.<p>Others I can think of off the top of my head:<p>vi[1], emacs, C, ethernet, smtp, ethernet, excel, rs-232[2], FTP[3]<p>There&#x27;s probably plenty of others too.<p>[1] in the form of neovim and vim in particular, but also nvi, busybox vi, and probably others.<p>[2] i just got a box from dell that has only one non-network way to interface with it: serial over usb. I had to remember how to set up my line parameters etc. Fun fact about xterm, etc: many of them allow you to do `xterm -l &#x2F;dev&#x2F;ttyUSB0 115200` way easier than dealing with picocom or whatever<p>[3] another fun fact, FTP is older than IP.

I like the Sharks not Dinosaurs thing. i keep see people saying &quot;the FAA system was so old&quot;... being old wasn&#x27;t the problem, lack of maintenance is the problem. We have roads that are old, bridges that are old, buildings that are old, planes that are old, ships that are old, that still do extremely well.<p>Rewriting COBOL in Javascript is not going to make a system more reliable. Making a system reliable is what makes it more reliable.

A fantastic list. And frankly the bit about context should be thing number 0. Context matters throughout everything you do in a system.<p>So many &quot;tech wars&quot; come down to &quot;you are both right in a different context.&quot; Holding a dogmatic view that &quot;we should always do X&quot; is usually detrimental (for some values of X).<p>I like people to have opinions, and to make suggestions, but I tend to take more seriously those who can discuss the downsides as well as the upsides.<p>For example, a junior I have tells me we need to switch to tool X. He lists 10 benefits of doing so. It&#x27;s obvious. We&#x27;re morons for not having done it already. Clearly we&#x27;re incompetent pointy-haired managers getting in the way of real programmers.<p>I ask him to argue the opposing point of view - why we _shouldn&#x27;t_ change. Sometimes the quick answer is &quot;there is no reason&quot;. But what I&#x27;m looking for is an acknowledgement of the impact of the change. The costs of retraining staff. The existance of existing code. The pushback from others. Etc<p>Only by understanding both sides can something be recommended.<p>I see juniors have this issue more than seniors. Seniors tend to understand that change causes ripples, and there are positives and negatives to everything.<p>Change is necessary. But jumping on every new thing can be disastrous.<p>Clearly my point works in my context, it may be different in yours.

Overall nice post. But the point 5, irks me the wrong way. Every time I read something along the lines of that paragraphs, something inside of me dies.<p>At expense of being downvoted to hell. I&#x27;m gonna say it in caps to emphasize, not to shout:<p>IT IS NOT THE RESPONSIBILITY NOR THE JOB OF THE SOFTWARE ENGINEER TO DELIVER OR PRODUCE VALUE.<p>This doesn&#x27;t apply to all Software Engineers (like the one who sells the product is also the Software Engineer, or writing open source libs to other developers, some freelancer,...).<p>It makes me sad to see how many Software Engineer are brainwashed to put up with the stress of producing value.<p>When people like PG, DDH or you name another CEO&#x2F;Cofounder, say: ultimately we should produce value. They are not talking as a Software Engineer, they are talking as people who owns and sell products&#x2F;service, who happen to be the Software Engineer of the product&#x2F;service.<p>I, as employee Software Engineer who produce software that other people use and a sell, must not be concerned about the value of the product&#x2F;service. My only concern is to design and implement what they ask for. Whether what they ask for as any value, it is not my responsibility. It is their money, they should find value in what they asking from me.<p>Why? Ask yourself if you are ultimately participating or have any say in the pricing of the product&#x2F;service? Or do I sell the product&#x2F;service myself? If you answered to No to both, then it is not your job to produce value.<p>I hope in the coming years we reduce the stress we put on Software Engineer. In the last years, I keep seeing this trend of making Software Engineer to everything.

There&#x27;s a lot to like here, but, as with almost all &#x27;advice&#x27; lists, the author makes the mistake of believing their own hype. They&#x27;re effectively saying &quot;I am a good developer, I do these things, therefore to be a good developer you should also do these things.&quot; It ignores the possibility that there are good developers who don&#x27;t do those things.<p>An example is the advice that &quot;Software engineers should write regularly.&quot; Why? Can&#x27;t you be an awesome dev if you don&#x27;t write? You definitely can, because I&#x27;ve met hundreds of great devs who&#x27;ve never written anything that you&#x27;d call &#x27;writing&#x27;. Devs who enjoy writing, and get something from writing, should absolutely write things. If you&#x27;re a dev who doesn&#x27;t enjoy writing then you probably shouldn&#x27;t force yourself to do it just because someone said it&#x27;s what devs should do. Find a different outlet that gives you the same thing other people get from writing.

Sometimes a pattern of an individual&#x27;s learning beliefs about X ends up something like this path over time:<p>1. X? I don&#x27;t know anything about X.<p>2. X is TRUE.<p>3. X is FALSE!!! (How silly to think it was TRUE! I&#x27;m on a higher plane of existence now!)<p>4. X is generally TRUE, but with caveats Y and Z.<p>5. X seems less relevant than P, Q, and R.<p>6. Better understanding of P, R, T, and V. But Q doesn&#x27;t seem as important as it used to.<p>At each step of understanding evolution, someone at an earlier step of belief evolution probably seems less enlightened.<p>And someone at a <i>later</i> step, along the same path, might <i>also</i> seem less enlightened. (Unless you have an opportunity to understand their thinking, and choose to take it, and are able to understand it.)

I love the idea of technological sharks roaming the software oceans. I&#x27;ve seen a few megalodons hanging around the mainframes too. Thanks for sharing a great list.

I think the less code the better is the aim but it is harder. This does not mean grab some massive framework, like Django, where you can write 10 lines and you have a whole application. It means taking a the time and care to keep things as small as possible from top to bottom.<p>It reminds me of the quote &quot;I have made this longer than usual because I have not had time to make it shorter. &quot;<p><a href="https:&#x2F;&#x2F;quoteinvestigator.com&#x2F;2012&#x2F;04&#x2F;28&#x2F;shorter-letter&#x2F;" rel="nofollow">https:&#x2F;&#x2F;quoteinvestigator.com&#x2F;2012&#x2F;04&#x2F;28&#x2F;shorter-letter&#x2F;</a><p>It is hard to make things simpler. It takes longer to code and, in the end it looks like you have produced less code. This is where the 10X developers come from.

As for the whole 10x programmer debacle... well it all depends really.<p>Are there people who are better at programming in general? Sure. But there are also plenty of people who just seem like that because the company they work for demands less than their full expertise.<p>The same dev who&#x27;s a &#x27;1x dev&#x27; at Google or Facebook or Apple might be a &#x27;10x dev&#x27; at a small web development agency, and a &#x27;100x dev&#x27; at a business which doesn&#x27;t specialise in software engineering at all. And the same goes in reverse. Point is, the environment and how well your practices gel with those of the team&#x2F;company have a huge effect on how productive you are, as do numerous other factors. It&#x27;s basically the whole &#x27;nature vs nurture&#x27; thing really, and both aspects play a role in how skilled a dev anyone is.

This hits so close home, I need to know if the author is a former colleague :)<p>I agree especially with two points: no one asks “why” enough, and the best software is the one that does not need to be written. Both often conflate as “we wrote it because we didn’t know we shouldn’t have”. I have lost count of how many times we asked “why”, just to find out that some engineer was having such a good time writing software that she ended up creating and integrating a shittier version of a widely known tool.

Check, check, check, yep, all the points are well taken. There is an OCD critter inside every developer trying to break free. We, developers, are stuck withing a rock (hardware) and a hard place (business). In my years coding (mostly C) I started paying less attention to code and more attention to people, their endeavors and motivations. It&#x27;s the whole package. I must say.

Re: #20: Always strive to build a smaller system.<p>There&#x27;s a quote I love I&#x27;ll repurpose here:<p><i>Forgive me this long program; I hadn&#x27;t the time to make it short.</i>

The point about innovation really struck a chord with me. I think most people really hate fundamental change which makes life more difficult.<p>However, users do like convenience: if you make something that is quite onerous to do, but the new method proposed is much simpler, has fewer physical steps to perform etc., they do tend to adopt it.<p>Which makes me wonder about the whole OTP thing...

&gt; 11. One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be<p>On the contrary. The more senior I get, the weaker my initial assumptions about everything becomes. The more I know, the less I know (so the less I push my ideas into other&#x27;s people&#x27;s minds)

To me, it&#x27;s simply: It&#x27;s easier, simpler 100x to manage 10 small services, than a service with 10 functionalities. Main reason is, i can easily swap out, replace any small service with better one. With big service, it&#x27;s impossible !<p>So it leads to next lesson: Learn how to compose things, or, thinking in higher level: Thinking in composition.

Good learnings. But there’s obviously very different jobs out there all called “software engineering”. Here we’re looking at the (perhaps most common) type where the challenge is to understand what software to build. But there are certainly other types, and the learnings there can be almost the opposite I would say.

I hope I&#x27;m not misinterpreting the point 11. As somebody with nearly 20 years in the field I found that the least knowledgeable people will often have the strongest opinions. Later in the career they learn there are no silver bullets, everything has trade offs and become more open minded.

On the sharks vs dinosaurs topic, I’m curious how this applies to languages and if C++ is a shark or dinosaur. Of all the languages that seems to be one on people talk about as being on the edge of extinction (Rust, Carbon, Cpp2, etc.) but keeps on going.

What a great post! I could relate to most of the points. It is for sure one of the best articles I’ve read which covers this particular topic. Thanks Justin for putting in the time and effort for sharing your thoughts.

&gt; 19. Interviews are almost worthless for telling how good of a team member someone will be<p>I definitely agree with this statement, but I would add `but at least allow you to discard who is definitely not good`.

14y of experience, good 10x devs do exists, but they are extremely rare. Everyone opinion is important, I learned there&#x27;s not enough different point of views, edge cases missed...

Past comments: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=28797485" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=28797485</a>

I have read this post probably 30 times since it was posted.<p>Having been a software engineer for +20 years so much good is in this piece.<p>Thx!

Great write up! After 13 years I find myself reflect on exactly the same points.

This is a very well written article, and thank you for the advice. Lots that resonates here.

Skimmed the article, saw the author quoted Bjarne Stroustrup, closed the tab.

Thoroughly enjoyable. My thanks to the author.

Kudos for the caveat that all advice is contextual

very good points, I agree with the sentiment, but the best code is not no code, it&#x27;s negative code

Love it!<p>Is there a way we can accelerate this learning?

&gt; If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system<p>I&#x27;m feeling like this is my next major skillset to improve. I&#x27;ve been building software for just over 6 years now and I can crank out a mean fullstack webapp in either JS&#x2F;TS or Python, I can deploy it on a few various cloud infrastructure setups I&#x27;ve used (or just a VPS really), I can plug it into various databases or database services-as-apis, to the point that whatever problem a client could bring to me, I&#x27;m pretty confident I could answer with &quot;yeah we can build that,&quot; and then do so.<p>But what I&#x27;m discovering is that there&#x27;s a lot of things already built, and that if I can learn to simply deploy &#x2F; integrate &#x2F; zip together the right already-built things, the possibilities for the services and solutions I can offer on a timely basis increase dramatically. The problem is I&#x27;m completely overwhelmed by the equations necessary.<p>A few concrete examples:<p>1. A local chain of ~20 hot pot restaurants approached me and asked if I could build a membership loyalty app (會員卡 APP), with features that allowed for tracking membership loyalty across the various brands and restaurants they have to promote cross-business sales. Sure, I could build that in react native, customer accounts, simple phone authentication, plug into the taiwanese version of twilio, plug into, i dunno, airtable, whatever db as a service I want. But wait, they also want to eventually display the menu, have an admin app to manage menu items, ok now we&#x27;re talking ecommerce &#x2F; CMS. I mean I <i>could</i> build that out from scratch but shouldn&#x27;t I instead try to plug in a headless ecommerce or CMS like medusajs or contentful? Well then I gotta deploy those, should I just get a VPS and throw them all on there? And what about the original member loyalty thing? Oh there&#x27;s plugins for that, they just cost 90$&#x2F;month, well fuck at this point maybe I should just buy a whitelabel restaurant POS system, then the only time I need to spend is in setup, then again, those are also expensive... but so is my time spent engineering whatever parts of this I need to do from scratch.<p>2. The local visa office is interested in a submission and display portal for immigrant stories here, something simple. They were considering submit.as as it&#x27;s basically the exact featureset they need, but the pricing is a little... much. Shit, an anonymous submission CMS with admin publish features? How hard could that be? That&#x27;s basically just a coding bootcamp project... right? Eh, imo it would probably take me a solid week or more to do something like that from scratch, or at least do it well, maybe I&#x27;m slow, but I decided instead to see if another platform could support that. Took me a weird amount of time looking at the bajillion CMS &#x2F; blog implementations before I realized Drupal can do that pretty easily, but the hilarious thing is I only know about drupal as of a few months ago when I was looking into various CMS for the restaurant app thing.<p>Basically I went 6 years in my career taking designs from designers &#x2F; executives and implementing them as new fresh codebases or in existing codebases. I&#x27;ve never really had the opportunity or projects where &quot;wait, isn&#x27;t this just a CMS?&quot; or &quot;can&#x27;t we get these features by deploying an ERP and using the API it auto-generates?&quot; were potential routes we could go down. Now that I&#x27;m touching that world, every time I start poking around, I&#x27;m totally overwhelmed.<p>I gotta admit I find it <i>much</i> more fun to be implementing custom SaaS or whatever else from scratch, I really haven&#x27;t enjoyed spending hours comparing hosting prices and license fees vs my estimation for how much time it will take me to plug x open source ecommerce UI into z open source ERP on top of y VPS service (and do the server requirements match??).<p>Mostly I just wish I was <i>better</i> at doing the latter because well for one it&#x27;ll let me pick up more gigs for my team cause we can apply ready-made solutions to a lot of people with the same problems, but also two because it&#x27;s fuckin cool how much work people have put into a lot of these open source solutions and I&#x27;d love to use and contribute to them more (I&#x27;ve already had some PRs accepted on missing &#x2F; incorrect deployment &#x2F; installation docs, it feels nice).

Love the list just a shame to see the 10x myth. 10xers really do exist but it&#x27;s hard to think about when framing it simply as 10x programmers.<p>These are people who see two levels of hierarchy requesting something for months and then builds a prototype over the weekend that solves 80% of the problem. Who sees two teams arguing for days back and forth and gets them together to make a decision with them and moves on. Who sees the hours wasted every day on bad tooling and bloat and makes the bold decision to cull and simplify. Who sees a product team losing a quarter building the wrong thing and is not afraid to shut it down with the boss. They know how to hire A players and raise the bar. They know when to hire. They know when to let people go.<p>They are not 10xers relative to 0.1xers, these are everyday 1xer situations.<p>They consistently have multiple magnitudes of impact. That&#x27;s not easy. For most of us that happens a lot less.

There is this myth that there are no 10x engineers. This is categorically false. I was a 10x engineer when I was employed. I could do in a day what would take people weeks. It&#x27;s an amalgamation of knowing the system, knowing how to try out ideas in isolation, knowing the editor well, a desire to build things fast and touch as few things as possible, aiming for simplicity and holding the big picture in the head.<p>So I think this myth is propagated by those who aren&#x27;t 10x engineers and just want to give up before getting there.