20 Things I’ve Learned in my 20 Years as a Software Engineer

20 Things I’ve Learned in my 20 Years as a Software Engineer

Important, Read This First

You’re about to read a blog post with a lot of advice. Learning from those who came before us is instrumental to success, but we often forget an important caveat. Almost all advice is contextual, yet it is rarely delivered with any context.

“You just need to charge more!” says the company who has been in business for 20 years and spent years charging “too little” to gain customers and become successful.

“You need to build everything as microservices!” says the company who built a quick monolith, gained thousands of customers, and then pivoted into microservices as they started running into scaling issues.

Without understanding the context, the advice is meaningless, or even worse, harmful. If those folks had followed their own advice early on, they themselves would likely have suffered from it. It is hard to escape this trap. We may be the culmination of our experiences, but we view them through the lens of the present.

So to give you a little context on where my advice comes from, I spent the first half of my career as a software engineer working for various small businesses and startups, then I went into consulting and worked in a number of really large businesses. Then I started Simple Thread and we grew from a team of 2 to a team of 25. 10 years ago we worked with mostly small/medium businesses, and now we work with a mix of big and small businesses.

My advice is from someone who…

  1. has almost always been on small, lean teams where we have to do a lot with very little.
  2. values working software over specific tools.
  3. is starting new projects all the time, but also has to maintain a number of systems.
  4. values engineer productivity over most other considerations

My experiences over the last 20 years have shaped how I view software, and have led me to some beliefs which I’ve tried to whittle down to a manageable list that I hope you find valuable.

On with the list

1. I still don’t know very much

“How can you not know what BGP is?” “You’ve never heard of Rust?” Most of us have heard these kinds of statements, probably too often. The reason many of us love software is because we are lifelong learners, and in software no matter which direction you look, there are wide vistas of knowledge going off in every direction and expanding by the day. This means that you can spend decades in your career, and still have a huge knowledge gap compared to someone who has also spent decades in a seemingly similar role. The sooner you realize this, the sooner you can start to shed your imposter syndrome and instead delight in learning from and teaching others.

2. The hardest part of software is building the right thing

I know this is cliche at this point, but the reason most software engineers don’t believe it is because they think it devalues their work. Personally I think that is nonsense. Instead it highlights the complexity and irrationality of the environments in which we have to work, which compounds our challenges. You can design the most technically impressive thing in the world, and then have nobody want to use it. Happens all the time. Designing software is mostly a listening activity, and we often have to be part software engineer, part psychic, and part anthropologist. Investing in this design process, whether through dedicated UX team members or by simply educating yourself, will deliver enormous dividends. Because how do you really calculate the cost of building the wrong software? It amounts to a lot more than just lost engineering time.

3. The best software engineers think like designers

Great software engineers think deeply about the user experience of their code. They might not think about it in those terms, but whether it is an external API, programmatic API, user interface, protocol, or any other interface; great engineers consider who will be using it, why it will be used, how it will be used, and what is important to those users. Keeping the user’s needs in mind is really the heart of good user experience.

4. The best code is no code, or code you don’t have to maintain

All I have to say is “coders gonna code.” You ask someone in any profession how to solve a problem, and they are going to err on the side of what they are good at. It is just human nature. Most software engineers are always going to err on the side of writing code, especially when a non-technical solution isn’t obvious. The same goes for code you don’t have to maintain. Engineering teams are apt to want to reinvent the wheel, when lots of wheels already exist. This is a balancing act, there are lots of reasons to grow your own, but beware of toxic “Not Invented Here” syndrome.

5. Software is a means to an end

The primary job of any software engineer is delivering value. Very few software developers understand this, even fewer internalize it. Truly internalizing this leads to a different way of solving problems, and a different way of viewing your tools. If you really believe that software is subservient to the outcome, you’ll be ready to really find “the right tool for the job” which might not be software at all.

6. Sometimes you have to stop sharpening the saw, and just start cutting shit

Some people tend to jump into problems and just start writing code. Other people tend to want to research and research and get caught in analysis paralysis. In those cases, set a deadline for yourself and just start exploring solutions. You’ll quickly learn more as you start solving the problem, and that will lead you to iterate into a better solution.

7. If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system

This is something I struggle with a lot as my responsibilities take me further and further from the day to day of software engineering. Keeping up with the developer ecosystem is a huge amount of work, but it is critical to understand what is possible. If you don’t understand what is possible and what is available in a given ecosystem then you’ll find it impossible to design a reasonable solution to all but the most simple of problems. To summarize, be wary of people designing systems who haven’t written any code in a long time.

8. Every system eventually sucks, get over it

Bjarne Stroustrup has a quote that goes “There are only two kinds of languages: the ones people complain about and the ones nobody uses”. This can be extended to large systems as well. There is no “right” architecture, you’ll never pay down all of your technical debt, you’ll never design the perfect interface, your tests will always be too slow. This isn’t an excuse to never make things better, but instead a way to give you perspective. Worry less about elegance and perfection; instead strive for continuous improvement and creating a livable system that your team enjoys working in and sustainably delivers value.

9. Nobody asks “why” enough

Take any opportunity to question assumptions and approaches that are “the way things have always been done”. Have a new team member coming on board? Pay attention to where they get confused and what questions they ask. Have a new feature request that doesn’t make sense? Make sure you understand the goal and what is driving the desire for this functionality. If you don’t get a clear answer, keep asking why until you understand.

10. We should be far more focused on avoiding 0.1x programmers than finding 10x programmers

The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly. I’ve seen programmers that sling 10x the amount of code, and then you have to fix it 10x the amount of times. The only way someone can be a 10x programmer is if you compare them to 0.1x programmers. Someone who wastes time, doesn’t ask for feedback, doesn’t test their code, doesn’t consider edge cases, etc… We should be far more concerned with keeping 0.1x programmers off our teams than finding the mythical 10x programmer.

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

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. You need to explore other languages, libraries, and paradigms. There are few ways of leveling up your skills faster than actively seeking out how others accomplish tasks with different tools and techniques than you do.

12. People don’t really want innovation

People talk about innovation a whole lot, but what they are usually looking for is cheap wins and novelty. If you truly innovate, and change the way that people have to do things, expect mostly negative feedback. If you believe in what you’re doing, and know it will really improve things, then brace yourself for a long battle.

13. Your data is the most important part of your system

I’ve seen a lot of systems where hope was the primary mechanism of data integrity. In systems like this, anything that happens off the golden path creates partial or dirty data. Dealing with this data in the future can become a nightmare. Just remember, your data will likely long outlive your codebase. Spend energy keeping it orderly and clean, it’ll pay off well in the long run.

14. Look for technological sharks

Old technologies that have stuck around are sharks, not dinosaurs. They solve problems so well that they have survived the rapid changes that occur constantly in the technology world. Don’t bet against these technologies, and replace them only if you have a very good reason. These tools won’t be flashy, and they won’t be exciting, but they will get the job done without a lot of sleepless nights.

15. Don’t mistake humility for ignorance

There are a lot of software engineers out there who won’t express opinions unless asked. Never assume that just because someone isn’t throwing their opinions in your face that they don’t have anything to add. Sometimes the noisiest people are the ones we want to listen to the least. Talk to the people around you, seek their feedback and advice. You’ll be glad you did.

16. Software engineers should write regularly

Software engineers should regularly blog, journal, write documentation and in general do anything that requires them to keep their written communication skills sharp. Writing helps you think about your problems, and helps you communicate those more effectively with your team and your future self. Good written communication is one of the most important skills for any software engineer to master.

17. Keep your processes as lean as possible

Everyone wants to be agile these days, but being “agile” is about building things in small chunks, learning, and then iterating. If someone is trying to shoehorn much more into it than that, then they’re probably selling something. It isn’t to say that people don’t need accountability or help to work this way, but how many times have you heard someone from your favorite tech company or large open source project brag about how great their Scrum process is? Stay lean on process until you know you need more. Trust your team and they will deliver.

18. Software engineers, like all humans, need to feel ownership

If you divorce someone from the output of their work, they will care less about their work. I see this almost as a tautology. This is the primary reason why cross-functional teams work so well, and why DevOps has become so popular. It isn’t all about handoffs and inefficiencies, it is about owning the whole process from start to finish, and being directly responsible for delivering value. Give a group of passionate people complete ownership over designing, building, and delivering a piece of software (or anything really) and amazing things will happen.

19. Interviews are almost worthless for telling how good of a team member someone will be

Interviews are far better spent trying to understand who someone is, and how interested they are in a given field of expertise. Trying to suss out how good of a team member they will be is a fruitless endeavor. And believe me, how smart or knowledgable someone is is also not a good indicator that they will be a great team member. No one is going to tell you in an interview that they are going to be unreliable, abusive, pompous, or never show up to meetings on time. People might claim they have “signals” for these things… “if they ask about time off in the first interview then they are never going to be there!” But these are all bullshit. If you’re using signals like these you’re just guessing and turning away good candidates.

20. Always strive to build a smaller system

There are a lot of forces that will push you to build the bigger system up-front. Budget allocation, the inability to decide which features should be cut, the desire to deliver the “best version” of a system. All of these things push us very forcefully towards building too much. You should fight this. 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.

What is your story?

So there you have it, 20 years of software distilled down into 20 pithy pieces of wisdom. I’d love to hear it if something resonated with you. I’d also love to hear if you have a piece of wisdom that you’ve picked up over your career that you’d like to share. Feel free to leave it down in the comments.

Loved the article? Hated it? Didn’t even read it?

We’d love to hear from you.

Reach Out

Comments (90)

  1. I’m glad I clicked this article even though I felt I’ll probably regret it as most listicles with similar titles are bound to disappoint.

    This one though, this was a true gem. Brown painted gold so to say.

    And I want to thank you for it. Will try to keep your advice close to heart in the future, just started my first engineer position this spring.

    1. Dom sums up my thoughts precisely – this is just about the first “list of N things” I’ve seen which I’ve actually thought worthwhile to spread to my networks. It would have saved us a lot of time if we’d had this when creating our Principal Engineers charter 🙂

  2. I resonate with point #19,
    I am a recent graduate and I’m trying to land a job as a software engineering role. It has been very hard and I know I can be a great asset to a team, I am always reading, learning new things and I have a experience with clients and leadership. Not long ago I had an interview and I believed I did a pretty good job, however I didn’t get the role. I guess the are looking for the perfect programmer who doesn’t make mistakes.

    By the way, I would I appreciate any help in my job search if anyone can help me. Thank you guys.

    Email: giovannyqtech@gmail.com

    1. Are there any aspects of the interview process you struggle with? Getting your first position can be tough because they don’t have the portfolio available to them as they would if you have years of experience. My advice? Create them that portfolio. Most jobs I have landed started because recruiters and such were browsing my git hub. There is enough value in that, some use it as their primary metric for determining competency.

    2. Gio – I’m sending an email your way too, but want to make this public as well.

      I am in no way affiliated, and honestly used it only a few times, however this is without a doubt the best tool I ever encountered when trying to level up my interviewing (which is different than working, as we all know).


      I never paid a dime for the service, so again, YMMV, but live interviews and studying other live interviews is where it truly is at.

      Good luck

  3. “The only way someone can be a 10x programmer is if you compare them to 0.1x programmers. Someone who wastes time, doesn’t ask for feedback, doesn’t test their code, doesn’t consider edge cases, etc…”

    This resonated very strongly iwth me. It’s me, I’m the 0.1 programmer :/

    1. I am currently working on two projects, one that I enjoy and another one that I hate. I am a 2x programmer on the first and a 0.1x programmer on the second, and I am not able to change this, even though I try to.

    2. Hey, take it easy. At work I’m sometimes a 0.1x programmer too. I felt pretty bad about it to be honest, like my coworkers were just a lot better than me. I started working on some things outside of work that I was really really interested in, and I noticed I was committing 10-15x more code per unit of time than I do at work — and it was good code, carefully written code that I was proud of and felt I wouldn’t be confused by at all if I came back to it in 2 years.

      Don’t get yourself down, just keep looking for the role that brings out the best in you.

  4. Thank you for this great article! It resonates very well with my own experiences from having worked as a developer. Many of these lessons applies to the entire field of software – one thing I missed was, to stop fixing someone else’s errors. That creates technical debt. If you make the error you have to fix it. It is an excellent learning opportunity. Also, if a vendor introduce a bug, we don’t make a workaround on behalf of the vendor. Use appropriate channels and make sure they clean up their issues.

  5. 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.

  6. Super insightful and totally true in my own 20yrs exp. It is the best 20yrs career advice in software engineering I ever read, I cant think of anything else… Thank you very much!

  7. > biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be

    I disagree with this: junior are more likely to repeat other’s opinions with convinction even though they haven’t experienced the issue that opinion was formed upon.

    Also let’s remember that opinions are always subjective: humility and open-mindness are definitely something I want in senior peers and those quality are so rare that cannot be taken for granted.

    I kind of agree with the following point
    > If you are using your tools, and you don’t love or hate them in a myriad of ways, you need to experience more.

    but I don’t think it’s telling if you’re senior or not.
    You just have bad tools, like most ecosystems or you found yourself comfortable in your set of things and somebody else has found themselves comfortable in others.

    Definitely against the
    > I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all.

    We’re building software. Violence should be as far away from us as possible. We’re not in trenches.
    We’re too early in this discipline to feel like it’s a badge of honor to be entrenched on one side of the debate. We should try to be open mind and look for other point of view and respect others opinions.

    1. > biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be

      You are right, but also that’s not really the essence of what he was saying. I’m sure you probably realise this as well. Sure Juniors have “opinions”, but they won’t hold up to any amount of interrogation. Most seniors will have reasons, backed by experience.

      It’s usually easy to figure out the difference between someone who was told an opinion and someone who formed one. So I still think the authors sentiment holds.

      > If you are using your tools, and you don’t love or hate them in a myriad of ways, you need to experience more.

      I don’t think the idea is that your current set of tools are the problem. It’s more that you haven’t looked around at all. Now if you love your tools and their productive, by all means. However, I would say it’s accurate that you can’t say whether or not your tools are good or bad if you haven’t tried others and started understanding the pros and cons. So in that sense it can show seniority in the sense that, you have enough experience with multiple tools to form opinions regarding when they are good/bad.

      > I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all.

      Here I think you’re just taking his hyperbole too literal. I’m the author doesn’t actually advocate for violence. We’re all allowed some hyperbole, otherwise writing, reading and general communication would become rather dull.

      I too would rather prefer disagreeing with someone, than having someone always go “Yea sure, that’s cool”. Some of the best ideas in software I’ve ever had came from “aggressively” arguing about solutions. Most of us are professionals and can separate the heated debates from personal matters.

  8. “Sometimes the noisiest people are the ones we want to listen to the least.”
    I have seen so many of this over the years, and often the best i have learn is
    from silent one.

  9. Thanks Justin, great article!

    As from 20y experience as a software engineer myself, I can add one more thing which I have learned.

    #21 Love your co-workers, or leave!
    I’ve found that to be productive and to be able to create fantastic value, I do not function very well (or at all to be more honest) if fellow co-workers / team-members are rude or inpolite. As an introvert (like the best software nerds usually are), I have not (and still do not) have the habit to defend my self or “kick back”, when ever an outrovert claim the ether during an entire lunch or a meeting, or even worse, is trying to be funny and give jokes that to me often are insulting (even it might not was intended to be!). When hiring, the most important qualification in my opinion, is how humble, polite and positive the attitude the candidate is. Bad attitude, negativism is poison! I tend to leave (any company) when I feel there is too much “poison” around, and that has been a successful strategy (at least) for me so far. Bottom line: find and stay in a team where you find love and passion in your co-workers, where you feel the optimism and positivity around you. Never allow people make you or your ideas less worthy. Your ideas or code may be optimized, but if people around you communicate this to you in a way that makes you feel bad, leave! Make sure to surround you with fellow co-workers that point out how great even your worst piece of code is. Good colleges will complement you for how impressive it is, even they don’t understand anything of it! It is probably “messy” for many reasons and you of all know why, and if allowed, know hows to fix it, better than anyone.

    Bottom line: Be aware of your social environment, you will only produce and feel happy about it when the environment allow you to do so! If the environment does not allow this, find a better environment that fits you!

    Take this from a simple guy that have created software that is valued billions on Nasdaq today!

    1. You’re actually deluded. You want people to be impressed at your worst code, and if not then they are toxic and you’ll just leave?

      I think the real lesson here is to pamper your introvert coding magicians, they need to be protected from reality or they will stop working for you

      1. Well, yes, in fact we will. The opportunities in software are too hot to pander to toxic engineering managers like you. Ever stopped to question why the average tenure in this field is like 2-3 years?

        If you want to retain quality talent, respect is essential. I doubt your performance evaluation by higher management will be stellar in a few cycles if this is how you see engineers under you.

  10. Oops, correction: not billions, sorry for getting carried away for a second there. It’s actually just a few $100 millions 🙂

  11. Awesome article! I’ve been working on transitioning to software for a while now and I like to listen/read to seasoned professionals so that I can be more effective and take into account things I might be missing.

    This is probably best article I have read in this topic and I’m glad I stumble upon it. Will share it with all my friends going thru the same motion of transitioning to tech.

    1. As someone who “transitioned to software” shortly after I learned to walk, here’s an observation & suggestion.

      So many people learn formulas or recipes and think they know technology. A monkey can see something done and repeat it. A parrot can hear something and repeat it. But they will be lost and frustrated if the parameters are changed slightly, or worse, if they need to combine elements of multiple skills into something new. You can be much more than a parrot or monkey if you choose to engage your human brain.

      So I suggest this: learn what you need to know, and then find out what that is built upon, and learn that too. Go as deep as you can. Why does it work? When might it fail? Who knows about it? Answer these questions for yourself.

      But don’t just focus on depth. Explore to the edges of your area, and look a little beyond them. What technical areas border your area of interest? What techniques do they have that might be useful in your area? What if you could combine areas? Is someone already doing that? What do you think is wrong with their approach, and can you improve upon it?

      You mentioned reading what “seasoned professionals” write. This is a very good way to learn. Take a look at stack overflow, hacker news, and similar sites, and just binge-read the answers or comments from high-scoring people. There are also practice websites like project euler and hackerrank where you can test your skills against others and again learn from those who are further along on their journey.

      Best of luck to you. This can be the most fun in the world, if you let it.

  12. As a fellow 20 year journeyman developer I can definitely subscribe to these. #11, the difference between a junior developer and a senior developer is that a senior developer has already made all the mistakes a junior developer will make. A corollary to points #2, #5 and #13: Always strive to fully understand the business/problem domain before you write a single line of code. The flipside of #19, when changing jobs, one of the main questions you should ask from a company is to describe their onboarding processes — how much effort they’re willing to expend on training you is a good indication of whether they are hiring someone to make a contribution or a warm body to fill the headcount.

  13. Hard to find anything in here that *doesn’t* resonate. This is one of the smartest, most useful blog posts on software development I’ve ever seen.

  14. Having been at a few companies where the ‘big refactor’ to get rid of ‘tech debt’ was attempted, a lot of what you wrote resonated. I came to the saying, “Every line of code you write, that doesn’t eliminate more than one line of code, is you building your tech debt”. Its too easy to point to the ‘legacy’ system as ‘bad’ and start building the ‘good’ replacement and end up with 2x the code to maintain. This usually happens when you get to the final 5% of what the legacy system does, and just run out of time. I’ve been at companies where there are more than three systems, the legacy, the first refactor, the attempt at microservices and the team is busy working on the ‘final refactor’.

  15. “Sometimes the noisiest people are the ones we want to listen to the least.”
    I agree with the title of this paragraph, but this sentence stung a bit. It’s true there is a true mix of intra and extraverts on any given day in a tech org. But I have met some very vocal, outspoken devs, directors, CTOs who are very active and present and “noisy” in the organizations and in many cases I have been thankful and better off from their amplified presence in my career. I think we need to further define what you mean by “noisy”. 5 years ago I had a CTO (who still makes sure they code often), do a presentation about Redux (new kid on the block at the time), to 200 devs. That same CTO also did a great talk on Testing strategies a few months later that I found instrumental in my career when it comes to strategizing about testing. I would consider this person to be “noisy” and thankful that they were. But I am humble as well as noisy in my current org and am open to hear your thoughts on this subject.

  16. Very well written points. I like all of these. I went through many of these and I understand how it feels.

    Thank you.

  17. I’ve been in the industry for over 20 years and #14 really hits home for me. I can’t count how many times someone with an affliction for “bright, shiny, new” things has wasted the time of the team and often the company while trying to make their favorite new technology of the week solve a problem that would have taken less time and effort to solve with what the team is already using. What these people are often lacking is the ability to really, thoroughly think things through to the end. The other thing that I see far too often is stagnation in learning. As you’ve said, to be in this field requires continual learning and people that refuse to accept that effectively tie themselves to the past and get left behind.

  18. I personally refrain from using terms like “cutting shit”, those who use such words and speak this way believe it makes them sound cool or real (not sure what exactly) but to the receiving end it sounds disgusting and communicates disregard of others and quickly erodes the respect and opens the door wide open for even bigger (cool and real) things to occur

  19. The more you think about a problem the better the solution. The better the why’s the smaller the solution. The more code you write the more the refactoring. You would at times be digging a hole to fill another and you need to come out sought of “unclutter” focus on the project otherwise you’ll scream micro service to every problem and keep at it till eventually you don’t understand what’s happening (possibly create a microservice to manage your microservice manager.. pun intended) …… Perfect read. Best developer blog I’ve read. Resonates to what’s happening in the field/industry even to DevOps engineers.

  20. Hey there, this spurred a lot of discussion in my group. May I use it as part of a survey with quotes and attribution back to your site?

  21. Justin, a warm shout from Stockholm!
    I have quit a few times my job over some of the exact same points you mention. I hope this is not some vision telling me i will end up quilting 20 times !?!?

    I can’t help but think that one reason why my learnings overlap so much with your points is I have been recently involved in creating an agnostic platform from scratch to build several projects, which rings similar to “starting new projects all the time, but also has to maintain a number of systems.” You are pressured into keeping things lean and focusing on engineer productivity. Otherwise you can’t easily bring in new people, nor can experienced people juggle multiple projects at once with minimal context switching. One day of onboarding for any newbie to take any change in several projects live, with the same confidence of a “git push” (literally, because we were doing gitops… Without knowing that’s what you call it :D)

    Anyways, thanks for writing this. I’m framing it!

    My baby is at https://github.com/rokmoln/support-firecloud btw but needs “productification”

  22. “The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly”

    I’m doing this all the time and I know at least one other developer doing the same :). It’s not related to amount of code, but how fast can someone solve problems and is building structures that allows do things faster and more performant.

    Regarding juniors I have same opinion like someone else here in comments, juniors are more likely to repeat other’s opinions and do things like they read in tutorial, but didn’t battle test solution first.

  23. I am retired after 35 years in the software trenches. Great list. #18 – ownership is particularly important, and drives many of the other areas. There was a reason that the developers of the original Macintosh computer (amazing things done by small groups of people) had their signatures embossed inside the case. Imagine if the splash screen that starts off a piece of software said “Created by: developers names” so the creators names (signatures) were a public part of the product. That simple thing would lead to better code! (Now I build musical instruments where every little thing is public. Immediately obvious how good that joint is.)

    1. It’s so true, it really does all come back to people taking pride and ownership of their work.

  24. I’m intrigued by #19. What do you suppose are the values in interviewing a candidate? What would you pay attention to while interviewing a candidate? And how would you decide on casting a must-hire/maybe/veto vote?

    A little about myself: I have around 10 years of experience working at small companies and startups; these companies and teams are lean and focused. I’ve been on both sides of table when it comes to interviewing and hiring.

    On the hiring side, I agree that looking for certain signals seems futile, but I have a hard time finding or coming up with a better approach.

    1. +1

      Is there some other way to tell if someone will be a good team member before hiring or is it impossible?

    2. 1. Asshole filter
      2. Relevant experience (or desire for)
      3. Shared values
      4. Communication skill level – careful to not let that be xenophobic, tho

  25. Your points innovation & interviews stood out for me. Thank you for taking time to share your experience with us.

  26. We need to venture more job opportunities in this sector and create a workable environment for the work..since the technology in computer is really taking us to another level in the coming years.

  27. The “10x programmer” concept IS the “0.1x programmer” concept, just from a different baseline. The original studies where the idea came from were measuring the productivity spread between the best and the worst performers, not between the best and the average.

  28. Fantastic article.

    Whilst I agree with your opening statement about context being hugely important, I think the sheer volume of comments talking about how much this resonates shows you’ve hit on some fairly universal software advice.

    My favourite point was on 0.1x vs 10x. It reminded me of the advice that up until a certain point you will win more tennis matches by stopping your own unforced errors than you will beating your opponent.

    I feel like too many developers strive to reach this mythical 10x status without thinking about what small improvements could make them a better team member.

  29. Hey, this is an awesome list thankyou. As a 50 year old who still loves working as a senior developer, all of this resonated with me, you’ve really captured a lot of important points here succinctly. On your point 7, I’d recommend having a read of a fairly new book called Fundamentals of Software Architecture which has a great chapter about knowledge depth vs. knowledge breadth – in summary, as you get more experience and do more design level type work, you need to increase the breadth of your knowledge – to know what is possible and what is out there. At the same time you’ll find you can’t have a depth of knowledge about everything, otherwise you’ll run yourself ragged. You can still focus on a few different specialist areas or frameworks which you keep up to date with, but you need to supplement this with knowledge breadth – a shallow and wide knowledge about as much as possible.

  30. Awesome article! Thank you very much!

    I would like to add something to #6:
    My experience is that you doing outstandingly well If you don’t pick the first solution that hops in your head for a problem. Instead taking your time to think about another solutions and compare them is a very economic act.

    1. Agreed, that is something I struggled with early in my career, and sometimes still do when under time pressure.

  31. wondering about the design of this site, why the comment is at the end of the page and why not just down below the post?

  32. Point 9 really irks me about a lot of companies. I see it at my job and I hear about it from friends who also work in IT in varying capacities. In an industry that’s built on change, maximizing efficiency, and finding new ways to do things it astounds me that so many companies refuse to charge the way things get done.

    I understand that some upgrades require massive restructuring that doesn’t always make practical or financial sense, but there’s just no excuse for certain things. No one questions why we’re still using this horribly buggy software from 1995, or why we haven’t automated a tedious but very simple manual process, or identified the source of a break in the process flow that confuses both the users and the devs who maintain the software. It’s maddening.

    Great points overall.

  33. A big problem of modern software development that people continuously rewrite existing systems to use the new technologies. For example, I have iPad of the first generation, it is fully functional, however less than 20% sites still work on it. Sure, sites I developed still work great. I can’t say that new software offers something completely different, for example Gmail stopped working on the iPad as six months, although I didn’t notice any new functionality in it. When developer will focus on creation something really new, then just try new technologies for old things?

  34. The 10x engineer (or more) *absolutely* exists – that this is even for debate with someone with 20 years of seniority is concerning, to put it mildly.

    Ever hear about dudes called Linus and Bjarne…? Ever hear about other guys that literally create their own OSes and game engines for fun…?

  35. This is a great article , a list i will keep in my bookmarks for long time.
    Couple of things i would add from my 18 years of experience from firmware development to web apps development, and integrating very large and poorly written components and dealing with 100s of engineers on daily basis.

    1- “Write code for others and do not own your code , write it so clean and easy to understand + review is so critically(publicly too) that people takes its ownership so easily without feeling any pressure from you. When you write for others to maintain then you become a developer who writes important parts of the system and pass to other people.
    2- And finally a very important thing, “never get scared, software doesn’t bite, trying to write something complicated or something you have no idea about is the safest risk you would ever take in your life, it pays high dividends. The sooner you are fearless the faster you grow”

  36. This is something I should have read some 25 years ago. Excellent mate..

    Some of the points are not just for Software Engineers, Eg. People don’t really want innovation.
    I have shared with my son, who is a budding SE in his B Tech.

    1. This year is 40 years of programming for me, as well, and I agree. This was an excellent list, probably the best of its kind I’ve seen.

  37. Great list, thanks! Folks should also check out the work of Marty Cagan at the Silicon Valley Product Group (svpg.com). He has a lot to say about all this and has distilled his wisdom into a couple of excellent books too (“Inspired” and “Empowered”).

  38. Great article! Amazing points. I have 15+ years in development, I can relate (in some way) to every single point.

  39. Regarding: “values engineer productivity over most other considerations”
    One of the most ignored part of software development I have seen in projects is “maintainability”:
    – Productivity of engineers are depending of the maintainability of the code.
    – Maintainability of code depends on followings:
    => Are you able to run and troubleshoot your application code line by line? (Mostly inside code editor on local machine or on remote machine)
    – People are adding more and more new services (sometime Heterogeneous service build with different languages/frameworks) and does not think about how difficult it will be to maintain it in future.

  40. Some great points.
    Really like the first point about “I still don’t know very much”. I often feel bad about not knowing details about some of the areas too like BGP/Rust etc
    But that’s the nature of our industry. There’s a huge amount of areas to dig into.

  41. Always understand the business goals you’re setting out to achieve.

    When I’m outlining a project, in a briefing or a requirements doc, I always start with the goal: “We need to email customers real-time tracking updates from USPS and UPS.” Or, “We want to find out which products are most frequently sold together.”

    Making sure the business goal is clear right at the top helps reduce scope creep and dead ends. And if the stakeholders can’t agree on the business goal, well, you can’t even get started.

    Another thought: there’s this gem from the Terry Pratchett novel Making Money, about the Igors (race of steampunk surgical/technological inventor geniuses), paraphrasing: “Igors didn’t build what you asked for. They built what you wanted.”

    If you’re clear on the goals, you can build what’s wanted regardless of what’s asked for.

  42. It’s hard to choose just one point, they’re all good. I’d roll with 2, 4 and 18.

    #2: I just had a conversation with someone; the company built an incredible (and expensive) software product that then produced almost zero income. Why? As ingenuitive as the product was, decision makers had no need for it. Asking a client questions about what they want, we really do have to read between the lines to give them what they need. And I’ll second what George Tucker said about Igors – that was funny.

    #4: Tech debt is a major topic – part of reducing it is avoiding it. I’ve seen some companies rewrite a product rather than maintain it. One lesson learned – figure out your assumptions and then question their validity.

    #18: I had to laugh when I saw tautology. I thought the first sentence worked both grammatically (though debatable) and mathematically (definitely).

  43. Just wanted to say thanks and give a big thumbs up. And extra thanks for the time it must have taken to put it together…that dedication to caring and trying to make the path easier for others speaks volumes.

    I’m in the 25+ years experience camp, and found zero points of disagreement. There’s a ton of wisdom here–hard earned, I’m sure–and it’s something I wish had been required reading when I started. Very well done.

  44. I’m a new software engineer and love to read articles like this that offers practical wisdom in bite sized chunks. It makes it easier to digest.

    Point number 6 stood out to me. Because of my lack of experience, I tend to overthink things which extends project deadlines, sometimes by a huge factor. I’ve been learning to just “cut shit” even if it feels like I’m making “mud pies” with my code. It sometimes helps just to get something working, and then think about how to improve it after. In most cases I end up iterating on the concept and producing something really great, which could only have happened by just starting.

    Thanks for distilling your experience, it is so valuable for people like me just starting out.

  45. Just the introduction part is valuable enough and even if the whole list was useless, it would have worth my time. I tried to pick which item is my “that’s it” one, but they are all so spot on that it’s impossible for me to favor one to others. Thank you for the brilliant article and kudos on your 20 years.

  46. Pretty much full ACKN.
    Guess I would only add
    “Always maximize code for readability”
    “Document your interfaces not the code”
    “Don’t try to ride dead horses”
    “RTFM i.e. documentation”

  47. Just the introduction part is valuable enough and even if the whole list was useless, it would have worth my time. I tried to pick which item is my “that’s it” one, but they are all so spot on that it’s impossible for me to favor one to others. Thank you for the brilliant article and kudos on your 20 years.

  48. Many thanks for the condensed experience of which many I could find myself in after more than 20 years of programming myself. I pretty much like the designer approach and call for simplicity. Team culture also is a big factor to success. Responsibility is another.

    One I missed, to me always helpful was/is
    “limit features in favor for stability and maintainability”.

    Users don’t miss and cannot complain on features that are not existing. However, features that are out there available to the users must be solid, really solid. In addition, any features not existing don’t need to be maintained. This means cost savings on upgrades, customer support and time savings for focussing on the essentials.

    In context, from an inner programmers view this means, less external libraries included can be more. Which is not meant to reinvent the wheel.

    Maybe there is another one.
    Standards are great, a working solution is even greater.

  49. This is a great post with very solid and helpful insight. I would love to share it more widely across my organization. It would benefit so many.

    I won’t do that.
    1. It contains profanity, so I can’t risk sharing it in a corporate environment, without expecting repercussions.
    2. I won’t plagiarize your work by editing it without credit.
    3. I can’t in good conscious reference or credit your work due to issue number one.

    Consider a few edits and you might change the world.

  50. Fantastic article. I feel like too many developers strive to reach this mythical 10x status without thinking about what small improvements could make them a better team member.

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *

More Insights

View All