A bunch of programming advice I'd give to myself 15 years ago

I&#x27;ll add one point. You are not your job. Don&#x27;t take things personally at work. And never be afraid to leave if you&#x27;re not fitting in with your company .<p>I&#x27;ve left jobs over a few reasons, primarily bad managers, increased compensation, and bad code .<p>If people are writing bad code at your company, to the point where you know it&#x27;s going to come back to haunt you later, it&#x27;s okay to just walk away .<p>Don&#x27;t embarrass anybody, don&#x27;t escalate to a manager and explain how horrible the code is. I was in a situation where someone our team was effectively writing code that pretended to do things it really didn&#x27;t. I got into a really nasty argument with half my team about this. I ended up putting in my two weeks, and then my manager was like oh you were right the entire time .<p>Life is too short to deal with incompetent people.

&gt; Try to solve bugs one layer deeper<p>This is one of the main things I try to impart to junior folks when I’m mentoring them or reviewing code.<p>It’s also one of the biggest red flags to me of someone who’s working above their level when I have to repeatedly press a more senior person to dig deeper and fix things at a deeper level.<p>You need to take the time to understand <i>why</i> the bug happened, or you’re just going to be patching wallpaper instead of fixing the plumbing leak.

Most of this advice has already clicked with me, but this part:<p>&gt; If you can&#x27;t easily explain why something is difficult, then it&#x27;s incidental complexity, which is probably worth addressing<p>That&#x27;s a real eye-opener. Hope I remember this next time I implement something complex. The thing is, I don&#x27;t think this stuff would&#x27;ve helped me much when I was a junior dev. A lot of them are just too nuanced.

Not sure what 15 years means, but if that’s where I started:<p>(Blasphemies warning)<p>- Skip low level and go as high as you can. Ditch C, assembly, hardware. Take python, ruby, js. Never touched C++ cause it’s awful? Good.<p>- All the money is in the hands of a client. If you’re taking it from someone else, best case you’re taking less than a quarter for essentially the same job. Useless leeches everywhere who perceive you as a magic money generator. Go around them once you’re confident.<p>- Read sicp, htdp, taoup, but don’t take them to heart. Seriously, extensively test any idea you learn against reality, cause ideas may sound excellent out of context.<p>- Pragmatic is the only way. Don’t listen to industry peasants jumping through imaginary hoops, they are crazy. Religion in programming is worse than religion irl. There’s insane amount of it in programming. Don’t argue, let them be. It’s actually easy to test approaches by yourself and learn your own ways. Most of these are just habits making no difference once learned.<p>- Doing something together only turns out faster if you’re <i>very</i> good communicators. Good communicators are rare and you are not the one.

I like this a lot. While those commenters who say it is too advanced for novices have a point, I feel these are still issues worth thinking about - and coming back to - as they learn.<p>The one exception is “Bad code gives you feedback, perfect code doesn’t. Err on the side of writing bad code.” My experience with bad code is that it does not tell me much; instead, it presents inscrutable and baffling mysteries. From the caveats and examples, I think the author is trying to say something rather different; something like “don’t obsess over completeness” or other concepts of ideal software - especially, I might add, dogmatic concepts of this nature.

The one thing I disagree is the thing about editors.<p>When I began coding I spent hours tweaking my vimrc file and learning all the essentially random shortcuts, and dealing with the absurdities of vimscript. (and debugging vim plugins that broke each other.) It felt like actual work while I was producing nothing.<p>Now I just open vscode with default settings and I am productive right away. Who cares about editors, vscode is good enough.<p>But maybe just vim sucks and I should have been playing with emacs all along, I don&#x27;t know.

The one piece of advice I would give myself 15 years ago:<p>In the corporate world be very good at administration. You only need to just be good enough at programming to not get fired. Everybody has opinions on software techniques and nobody measures anything, so it’s really just a popularity&#x2F;tool game. The only goals are retain employment or promote out of software, being good at software is just a distraction from the goals.<p>If you want to be excellent at programming do it as a hobby and set your expectations right that it’s only a hobby.

Those are way too abstract advice when you start programming.<p>You can only understand them because you lived those situations, which implies experience you don&#x27;t have.<p>I would say (specifically to my young self):<p>- There is no substitute for doing. Less tutorials, more coding.<p>- Stop being obsessed with quality: you are not at the level where you can provide it yet. Do dirty. Do badly. But ship. Some people will be mad at you, and they are right. But do it anyway. Yes, reboot the servers with users on it. Yes, commit the spaghetti. You&#x27;ll reach the level you want to avoid doing all this.<p>- The users don&#x27;t care about the tech. They care about the result.<p>- Doing something for the hell of it is worth it. Just make it separate from the point above so they don&#x27;t conflict.<p>- Programming is a battle against complexity. Again and again. Put that on a post-it. Make your decisions based on it. You will suck at it, but try.<p>- You have imposter syndrome because you are an imposter. You are really bad. It&#x27;s ok, doctors hurt people for years while learning to save them. Don&#x27;t sweat it. It will come.<p>- You need faith it will work out. On the long run, you&#x27;ll get better at this. But in the short term also. You&#x27;ll find the bug. You&#x27;ll figure out the solution. It will happen if you keep at it even if it can be frustratingly long and unfair. Even if it doesn&#x27;t feel like that right now.<p>- The right team is way more important than the right tech. If you are alone, get in touch with people who will lift you up from time to time.

This was great. I particularly enjoyed the &quot;Bad code gives you feedback, perfect code doesn’t. Err on the side of writing bad code&quot; section, I&#x27;d never thought about how spending time writing &quot;perfect&quot; code means you don&#x27;t get to figure out which aspects of that code actually matter.

This is interesting. If I were to complement the list, these are some items I’d add that helped me:<p>- learn functional programming. Doing that was how I finally “grokked” programming and could solve problems more easily. Before I was ready to give up.<p>- learn CS history. I studied UX and what I learnt was mostly one side of how to think about computing where you spoon feed users and remove things. There are other ways to conceptualize software and design, which would have left me less disillusioned.<p>- learn fundamentals: data structures, networking, performance, operating systems, security, unix, math. These are so neglected in the industry, and we’re left with super complex systems we don’t actually understand as a result.

I wish more articles talked about the usefulness of integration tests over unit tests. Personally, I feel that unit tests are overrated and rarely give the required confidence to inform the team whether something is ship ready, whereas integration tests on the common workflows means that even when a bug is introduced, very few users are affected.

&gt; If you can’t easily explain why something is difficult, then it’s incidental complexity, which is probably worth addressing.<p>This one is good and has been following me since I&#x27;ve became a manager. Thanks to you, I know how to apply that objection to &quot;press&quot; people when I feel we&#x27;re dealing with this kind of complexity.

Agree with sibling comment saying these are too abstract. Here are mine:<p>Fundamentals:<p>- Ecosystem beats language and syntax<p>- Use boring, battle tested technologies<p>- Use the relational database to do the heavy lifting<p>- Avoid caching unless you have a great reason<p>- Code cleanliness comes from simplicity, not elegance<p>- There&#x27;s higher leverage from improved code reading ability over writing ability<p>Professional:<p>- You grow faster building in good industries over interesting codebases<p>- There&#x27;s higher leverage from improving the business over improving the code<p>- There&#x27;s higher leverage in finding mentorship over being an autodidact<p>- Make T-shaped buy vs build calls: build the secret sauce, try to buy the rest<p>Probably leaving a bunch out.

I rarely see advice with which I wholly agree. This is one of those rare times that I fully agree with everything g. Good seasoned advice from someone that has been doing this fo r a while.

Mostly pretty sound advice here, but oh, this rankles! --<p>&quot;In situations where bugs aren’t mission critical (ex. 99% of web apps), you’re going to get further with shipping fast and fixing bugs fast, than taking the time to make sure you’re shipping pristine features on your first try.&quot;<p>In 99% of web apps, your end users have no possible way of telling you that you shipped a bug, and your bug will remain there forever, frustrating users and losing your client money as they abandon your site. Telemetry won&#x27;t help you either becuase you&#x27;ll misunderstand the observations it provides.

&gt; Assess the trade-off you’re making between quality and pace<p>Very important! But also important to distinguish between <i>kinds</i> of quality. Using a sub-optimal algorithm or bad identifiers or copy-pasted code can always be fixed later. But some problems like a bad database schema is much harder to fix later.

The author’s comments about knowing your business context and the potential impact of bugs really hit home with me.<p>I have seen far too many teams using Facebook sized solutions for a few thousand users.<p>I’ve seen developers slowed to an absolute crawl, terrified of shipping code, for a completely secondary operational platform with low volumes and non-critical data. All because the product people were misguided in their mission.<p>And sadly, I’ve seen teams with almost non-existent security practices and knowledge happily banging out crap in financial services environments.<p>And I’ve been blessed with teams understanding their position and fully embracing it. Financial services products with quarterly releases that were rock solid and well architected. Batch document processing systems with just a few dozen end users who worked closely with us developers to tune algorithms where sometimes we would ship multiple times in a day and re run batches in production.<p>To be successful, teams gotta know if you’re at NASA level, or life threatening, or business critical, or somewhat critical, or just nice tooling, plus understand the cash flow &#x2F; budget situation. As a dev you may not be privy to all that, but strive to know as much of this as you can.<p>And of course, understand who you users are, and who your customers are, and prioritize accordingly.

My advices to new software engineers:<p>- Always think how to simplify the code you write, since simple code is easier to maintain and debug.<p>- Prefer writing dumb code than smart code. Smart code is good for programming contests. Smart code is very bad in production when it needs to be debugged or refactored.<p>- Always think about improving the usability of the software product you work on. Users don&#x27;t care about code. They care about UX of your product.<p>- Fix small usability issues as soon as you notice them, since these issues are usually the most annoying for end users.<p>- Do not start writing code with some popular design patterns. Just write the most simple code, which resolves the given task. Later, the best design patterns will evolve organically from the code solving the particular task.<p>VictoriaMetrics development goals are based on these rules - <a href="https:&#x2F;&#x2F;docs.victoriametrics.com&#x2F;goals&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.victoriametrics.com&#x2F;goals&#x2F;</a>

I have one:<p>Learn to become comfortable implementing and working on state machines.<p>It might be one of the most useful abstractions out there that if implemented well leads to a great extensible design without compromising performance.

The point that resonated most with me, and that I repeat every time someone early in their career asks for advice (or one thing I wish I had been told when I first started out) is &quot;When working on a team, you should usually ask the question&quot;.<p>Early in my career, I spent a lot of time reading unclear or obsolete documentation, poring over code, etc, when I could have asked the person sitting next to me and gotten an answer in 5 minutes. Sometimes, I didn&#x27;t even know who the right person to ask was, but if I had just asked my tech lead, he would have been able to point me in the right direction.<p>Claiming that it reduces your overall time from several hours to &lt; 5 minutes is maybe a bit exaggerated, since it also takes time to figure out what question you want to ask in the first place. But it&#x27;s still worthwhile even if you end up investigating for 30 minutes instead of 3 hours.

&quot;Don’t underestimate the value of digging into history to investigate some bugs.&quot; Valuable advice, and it particularly highlights the risk of global state and the benefit of understanding your runtime. Browsers have popularized flamegraphs, stack traces show you the frames down to the moment of error, but global state survives multiple stack traces and the one you&#x27;re looking at may not be (probably isn&#x27;t) the cause of the problem. There is global state, the heap, external systems, etc that change over time and with successive calls. This is true even in single-threaded environments, and is far more complex in general multi-threaded environments. I often feel this isn&#x27;t clear to beginners nor is it clear to them how you go about investigating bugs within this context.

The trick is not in having advice to offer. It’s in having advice they will hear.<p>Next month I’ll have been working in software for 30 years. Which means I would have a lot more common ground with me 15 years ago than most people will. that me with five years’ experience might not have understood at all.<p>Me with five years’ experience suspected many things that were true but missed some important one. I’d probably have to feed his ego by confirming some of those things before moving on to the difficult bits.<p>But who is to say that me with less Impostor Syndrome would be a better person? No, the main value in learning from the past is improving the future, not nostalgia or regrets or what ifs.

&quot;Bad code gives you feedback, perfect code doesn’t. Err on the side of writing bad code&quot;.<p>This is probably quite a cynical way of putting it (and it speaks to me, probably because I am quite cynical) though I don&#x27;t know if a junior dev will really appreciate this.<p>The way I would put it is: don&#x27;t seek satisfaction from trying to make perfect abstractions for business rules no one quite understands, rather seek satisfaction from making your user&#x27;s lives easier as efficiently as possible.

One bit of programming advice I would give myself is, on large projects, ensuring that appropriate constraints are in place is more important than functionality. You want to be able to come back to an area of code after a few years (without looking at it) and everything that has been added should still make sense. Patterns that you don&#x27;t want to see should be hard to do - the natural inertia will stop it from happening. Designing things that &quot;allow people to do anything&quot;, while seemingly a benefit, end up causing a lot of problems in the long run.<p>A reasonable argument might be that it should be watched &#x2F; policed but this is harder in practice than in might seem. A lot of orgs are fairly decentralized, meaning that no central entity can make the call (probably a good thing imo). If appropriate constraints are designed into the system this kind of energy sapping discussion will not even need to happen in the first place.<p>Essentially, adding constraints at t0 adds degrees of freedom in the future. Coding is a bit like a garden - you need to ensure that the garden makes sense as it grows.

A variant on that I say on one of these is &quot;Do the dumb thing&quot; thing to find the right abstraction. I&#x27;ve seen so mucb code that didn&#x27;t need to be written if someone had just done the dumb thing. On the flip side, I&#x27;ve also seen so much code that could be so much simpler if after writing the dumb solution, they went back and figured out a better one. I guess the takeaway is: Prototype.

&gt; Spending time sharpening the axe is almost always worth it<p>I hear this advice constantly. But I feel like it really need to be qualified. I have been in projects that never saw any real value produced because people constantly focused on DX, projects management, and other tools.<p>Sometimes one just needs to do with tools at hand, and not worry if there are better tools.

&gt; &quot;It’s really easy to write terrible code. But it’s also really easy to write code that follows absolutely every best practice, with 100% test coverage, and has been fuzz-tested and mutation-tested for good measure – your startup will just run out of money before you finish. So a lot of programming is figuring out the balance.&quot;<p>The situation appears to be changing rapidly. 15 years ago there were no advanced code-generating LLMs, and while relying on them for the core logic without having a good understanding of the language and system is still a bit iffy, it does seem that they&#x27;re pretty good for generating tests and spotting deviations from whatever your group has decided are best practices.

&gt; Our server models are exactly the same as the DTOs we would write, so I just serialized those, instead of writing all the boilerplate, we can write DTOs as needed later if needed<p>I worked on a system that used the protobuf types generated for communicating between services <i>everywhere</i>. There was absolutely nothing in any of the components of the system that didn&#x27;t depend directly on the generated protobuf code. What made it even worse is that a backend system we called had multiple endpoints that used the same name for similar but slightly different things, so there wasn&#x27;t, e.g. just a single Passenger type, but a bunch of different Passenger types across various packages.

<i>&gt; update our subscription layer to call subscribers on the main thread instead</i><p>I often do this, but have been doing it less frequently, lately, because I don&#x27;t want to force a thread switch, unless I <i>know</i> that I&#x27;ll be calling UIKit functions (not always things that affect UI. Many &quot;background&quot; UIKit functions also require main thread). Instead, I clearly mention the thread state, in the API headerdoc description (<i>&quot;- parameter handler: A simple, no-parameter, tail completion. May be called in any thread.&quot;</i>).

I spent a ridiculous amount of hours tweaking my vim config over the last two decades. I&#x27;ve used vscode the last few years and rarely jump to vim to do some text manipulation (that I usually could do with a raw install)

Good post, I agree with most of it. One that goes hand-in-hand with &quot;just ask the question&quot; is learning to know when to pivot. If you&#x27;ve hit a blocker, whether it&#x27;s something to do with waiting on a teammate, client, or answer to a hard question, consider pivoting to another task to knock out some easy wins.<p>Ideally the task you pivot to should require minimal context switching to get going. This way you won&#x27;t lose productivity. Often if the blocker is a hard problem and you go back to it later, you might have a good idea after stepping away for a bit as a bonus.

I would have told myself that there&#x27;s going to be a new frontend architecture called &quot;SPA,&quot; and a new framework related to it called React.js. And that I should stay far away from both of them.

This is one of the better advice posts I’ve seen. Especially the parts about finding the balance between shipping fast and shipping bug-free code.<p>Too many engineers think their job is “great code writer” and not “value adder”

Really great advice! Few that I would add based on my experience:<p>- Engineers spend way more time reading code than writing it. So writing easy to read code is more important than writing fancy&#x2F;complicated code just because it saves few lines of code.<p>- Extension to above point. Having coding standards in the company is important so that it&#x27;s for anyone to make changes to different parts of the code. If one engineer ends up writing code using their own standards, it makes life harder for everyone else on the team every time anyone else has to debug that code.

Seems like some good advice here! The points about digging deeper into the cause of a bug and looking at the history of the codebase for more info are really good points to keep in mind for sure.<p>And remembering to ask questions hits home pretty well too. There&#x27;s always the worry that you&#x27;re bothering people too much, and the balancing act between thinking whether you need to be asking for help early enough to make sure you&#x27;re not going down the wrong path and not asking about every little thing without attempting to fix it yourself...

not a good advice at all. it&#x27;s hard to interpret right and will probably change in 5 years anyway when the author reaches another stage.<p>my advice would be much simpler: 1. Most of the time you&#x27;ll be manipulating test. Learn options how to manipulate text professionally. That includes vim, bash, sed, awk, perl, and regexes in general, including lookbehinds etc. It&#x27;s worth it. It takes a few years to learn but even the basic options give you the culture and approach how to do things faster. Most coders have trouble swapping two columns in a text file or finding unprintable character.<p>2. Learn hotkeys seriously. They&#x27;re more consistent and uniform than UI, learn how change them, which tools are better designed for them, and organize some memorization scheme. It pays off a lot and gets into body memory, freeing up mental space.<p>3. Learn how to version your own code instead of creating multiple files and folders. Read git manual at least once. Learn how patches work, what is interactive rebase, and how to go back and forth, combining different changes from different branches. That gives you freedom to experiment with code on a larger scale.<p>4. Learn how to quickly test any framework&#x2F;code. There will be countless situations where you have some piece of crap not producing the needed result, and you should be able to quickly prove it. For this p.1 is invaluable. I have my own json,xml,rest,kafka and text log parser and diff, and a few cloud, database and search clients which I tweak when switching jobs. It&#x27;s all mostly written in standard unix tools, and can be literally retyped if needed (I worked on high security envs often). It&#x27;s also isolates me from poor (non-)standard tooling different in every enterprise to which I only fallback when I already know the answer and need to prove it to a peer.<p>The rest is subjective and optional. You can love or hate your job, you can love tabs or spaces, weak or strong typing, but the above will definitely makes it faster. What to do with the rest of that time is your decision.

&gt; If you can’t easily explain why something is difficult, then it’s incidental complexity, which is probably worth addressing<p>That’s how I feel about git.

&gt; If you (or your team) are shooting yourselves in the foot constantly, fix the gun<p>This is a reasonable step to take if you&#x27;re working in a reasonable company with reasonable &quot;management&quot;. If you&#x27;re unlucky enough to be working under a manager that refuses to recognize there is a problem, even with compelling data, prepare for pain. In that case nothing is allowed to be done because &quot;well, that&#x27;s how we&#x27;ve always done it and doing something about it might upset someone&quot;. It&#x27;s really time to quit and find something new at that point because there is generally no hope of turning that around.<p>&gt; If you can’t easily explain why something is difficult, then it’s incidental complexity, which is probably worth addressing<p>See above. &quot;That&#x27;s how we&#x27;ve always done it, and someone is used to that work flow, so we can&#x27;t change it.&quot; Sometimes this will lead to a legitimate Chesterton&#x27;s Fence situation, in which case you&#x27;d want to regroup and rethink it. Otherwise, the batshit insane is the default. Target the latter.<p>&gt; Try to solve bugs one layer deeper<p>&quot;There is no time to do that! We have so many other projects!&quot; While being blind to the fact (or better yet, burying their head in the sand and trying to ignore) that it&#x27;s all self-induced.<p>&gt; Don’t underestimate the value of digging into history to investigate some bugs<p>&quot;We can&#x27;t change that because one of our people close to management made that decision and it might drive them away.&quot; Good, get them out, that&#x27;s the only way to really fix it. Ideally if the management that hired them is pushed out too.<p>&gt; When working on a team, you should usually ask the question<p>&quot;Who are you to question our wisdom? Who are you to suggest something else, it&#x27;s working in production.&quot;<p>These are great things to start conversations, but you have to start them in an organization that is willing to change and be willing to take your advice to heart. Don&#x27;t waste your precious life trying to change what can&#x27;t be change, no matter how much you want to see it change.

this is not on the content but on the website color choices for text and background: wonderfully well done, easy to read in dark mode. with this kind of sensible coloring i feel i don’t need eink devices for reading.

One more: Make developer velocity one of your top priorities.<p>You should be able to give anyone in your team the repo URL and have them running unit and local integration tests in five minutes without prior knowledge.

Funny how he casually mentions JIRA as a process that slows you down. I get that his team does the issue tracking somewhere else?<p>What does people use that is faster to process both for devs and the PM?

&gt; Keep doing the first sort of bug fix, and you end up with a mess.<p>To avoid the mess, design with the fail-fast principle in mind, which brings you closer to the spot where an error occurred.

I think this is great for the craft of coding and solving problems. I’d add one more, along the vein of career advice: you’re hired to solve problems for the business, not to solve technical problems. If you can’t explain how the thing you’re doing makes an actual difference for the business, you need to reflect on what you’re spending your time on. I’ve seen too many technical teams be far too fixated on technical problems and unable to understand why they can’t get more headcount, funding, or recognition. Nobody writing checks cares about code.

Advice I&#x27;d give myself:<p>Finish what you&#x27;re doing.

Very reasonable, solving bugs one layer deeper can be very valuable, if you don&#x27;t go too deep into the rabbit hole.

15 years ago? Just buy bitcoin

What about: buy Bitcoin?

&gt; Don’t underestimate the value of digging into history to investigate some bugs<p>I&#x27;m one of about 2 people at my company who goes on archaeological expeditions to understand when and why a bug was introduced. A nonzero number of times, I have found that the behavior was introduced on purpose over a decade ago, and sometimes it&#x27;s addressing an edge case I didn&#x27;t think about. History is valuable!<p>(unfortunately the most common usage for me though is as a &#x27;smell test&#x27; where I learn who wrote the code from the history and then decide based on my existing assessment of their skills, how suspicious I should be of that code)<p>e; oh yeah one more story that&#x27;s kinda funny. Just this week I saw some behavior that I didn&#x27;t like and went to look at the code&#x27;s history. I was the one who wrote the code I didn&#x27;t like. But I had left a good enough comment on it that I realized there actually was no issue at all and my expectations were incorrect.

programming is such a young field wirh many iterations that good advice is hard. I should have probaly made my own programming language!

I loved the author&#x27;s point on &quot;incidental complexity&quot;. I would point out though, that even if you CAN explain why something is complex doesn&#x27;t mean it SHOULD be complex.<p>When the subject of &quot;tech debt&quot; comes up, I always tell the teams I work on to focus on tasks that improve our speed or agility in the future. I believe that many coding tasks actually have a <i>negative</i> dev cost over time, as they reduce the dev costs of future work more than they cost at the current moment to implement. (Of course the problem is that they have a positive dev cost in the current sprint, so good luck convincing decision makers...)

Codeisforhumans.com

&gt; You’re going to be renaming things, going to type definitions, finding references, etc a lot; you should be fast at this. You should know all the major shortcuts in your editor.<p>Programmers love to think this matters. If you&#x27;re doing anything more than the most rudimentary work, the time &#x27;saved&#x27; by maximizing keyboard shortcuts is completely irrelevant. You&#x27;re spending most of your time reading code, thinking about that code and thinking of what code you&#x27;re going to write.<p>When any programmer emphasizes how fast they are at completing these rudimentary tasks, my assumption is they are less adapt at the actual work of programming and instead try to &#x27;git gud&#x27; at the keyboard wizard bullshit.