I've been working with one junior and one not so junior programmer on a hobby project recently, and they are both "Right Way Guys". For a roughly 300 LOC project with a discord bot and some rust code that only we will be running for now, they insisted on complete documentation, separate VMs for QA and "prod", systemd deployments, a templating system for a few strings, an ORM layer for four (4) SQL queries.. this is a project that maybe 10 people would use. These are only half the requirements for the "0.3" release with much more over engineering planned for the future. I have stopped working on that project :)
It's frustrating and sad to see people do that. I was myself a "Right Way Guy" at the beginning of my programming for a few years, before I learned how much depth there is in CS besides junk like best practices and code style and how to focus on the only thing that matters - working code. They are often too convinced of their rightness.
The situation you described doesn’t sound like “Right Way Guys”. It actually sounds like “Bikeshedding” [1]. This means giving a disproportionate amount of attention or importance to the trivial details while neglecting or giving less attention to the significant issues.
Imagine a committee commissioned to approve plans for a Nuclear Power Plant. But the committee spends all their time discussing the color of the bike shed that they want built nearby.
In your case, their focus on separate VMs for QA/Production, systemd deployments, templating system for a few strings, and an ORM for a few SQL queries, especially for a project with a limited user base (10 people) really exemplifies Bike-shedding.
They’re emphasizing minor, arguably unnecessary details rather than the core functionality or purpose of the project [2]. This usually occurs because these trivial aspects are easier to understand and discuss, especially for junior devs, which leads to increased involvement on minor details while the more meaningful parts of a project (which might be more challenging to address), are overlooked or given less attention.
IMO, a good leader knows how to strike a balance between the “Right Way” and avoiding the pitfalls of “Bike-shedding”.
I'd argue that they're not completely wrong in doing those things.
Many of those things you list really don't take too much time to do, like writing systemd units or using an ORM. But they really help when anyone needs to take a look at things in the future or someone else wants to contribute as well later on. Besides, they're easier to do when things are still fresh in the mind, and these kinds of chores rarely get done later on when a project has grown.
This being a hobby project may also be a reason why the other programmers want to do things right; they may get satisfaction and learn new things by doing it this way!
In the movie Primer, a group of four friends start a small computer business on the side. Two of them later invent a sci-fi box and then dramatic shenanigans ensue.
Something I missed at first [1] was the significance of an event that happens early in the movie. They need to buy a $50 router because their existing one is broken. They have an impromptu meeting where one of the characters gives suggestions on how they could try to fix the existing router. The suggestions are all half spoken before being answered: "Did you try the ..." : "yes"; "well , how about resetting the ..." : "I tried that too". Clearly they're basically reading each other's minds because of how well they know each other and how much time they spend with each other.
But then comes the 'punchline'. One character says 'yes' to buying the new router. The other response with "I need an 'aye'". Their side business apparently has very strict rules about what words they need to use for voting on decisions. It doesn't matter that they all know each other so well that they're finishing each other's sentences. It doesn't matter that this is a $50 router. And it doesn't matter that their income from this side business is inconsequential. The rules say that they need an 'aye'.
My own theory with "Right Way Guys" is that some people have been able to find a lot of success by leveraging the knowledge that's stored in the hivemind of society. They don't really know what they're doing when you consider what's going on inside their skull. But they have successfully copied success up till now. The plus side is that they're able to inherit successful methodologies that have survived over time without having to do all the hard work themselves. The down side is that they literally don't understand when they're in a scenario where it will lead to failure. [2]
[1] - I didn't think much of this until I watched the director commentary. Where they explicitly talk about how they intentionally setup this interaction to showcase how certain characters took the rules too seriously and which ones didn't take them seriously enough.
[2] - My theory on my theory is that this is also why so many people encourage others to join in their favored cargo cult practice (be it software development or anything else). Social behaviors may or may not work, but the more people you can convince to follow them the greater the chance that when they fail catastrophically and/or fatally they're failing for someone who isn't you.
Ha, reading first part I got incorrect feeling you are actually proud of that approach, I thought 'geez not again this'. Luckily I read till the end :) I see it all the time, well most of the time these days. I call those folks smart juniors, and it literally doesn't matter if they have 1 or 20 years of experience.
Smart juniors know most if not all design patterns, read Mythical man month, and so on, and... is super eager to try new technologies, languages, frameworks and is literally running around with shiny new hammers desperately looking for anything resembling nails. And then they do some stupid decisions because they don't grok the power an optimized boring old DB can bring in.
Then comes a guy like me with 20 years of experience who has seen damn well how such projects end up 5-10 years down the line with half if not most of the original team gone, and cuts half of that crap out while keeping genuine added value, because we are not running kindergarten for devs who want to have fun at all costs all the time, we work for our business who pays us and expects good, stable and relatively quick deliveries, rest are details on our side. You can't be taken seriously by business if you behave like that, no matter how good your intentions are.
IMHE bleeding edge stuff and trying new things for the sake or avoiding boredom will consistently break more down the road than it will help fixing. We incorporate technologies which whole team can grok and be proficient in, not just some bored superstar. Build your CV elsewhere if you desperately want as many technology entries as possible, there are companies like that, and good for them. IMHO these folks anyway don't stay around for too long so full added value is even questionable, the grass is always greener elsewhere, at least till they get there. Could be boring for some, I call it seasoned (yet still endless amount of stuff to learn, but that's fine this won't change till my retirement).
Building things the right way is a chance for people to learn tools and have fun. They're more impressive if your goal with a side project is for companies to look at your GitHub page.
Documentation is crucial. I have some fairly basic <300LOC projects including a bot and a web scraper that I currently cannot run because I didn't document them. The Raspberry Pi they were running on died and I need to do....something....to fix my headless virtual framebuffer and debug some cryptic errors that do not find productive search results.
If I had containerized or, at a minimum, documented my setup steps, I would not have this problem.
What's tricky is that in a different context, those people would be excellent contributors. Like in a mature product, who wouldn't love a developer who works on documentation, builds out a staging environment, and makes the codebase more scalable? But it just doesn't make sense when you haven't shipped anything yet.
I initially was expecting you to make excuses like "yeah, our code has undefined behavior, but it works, and only 10 people will use it". This is how I've seen the "but it works, just get shit done" attitude employed among my programming peers. People use "but it works" to excuse things don't don't actually work.
In the end, I think you're right though. As long as the code is reliable, then the shortest code is the best code (within reason, don't start playing code golf). It takes an awfully good abstraction to beat simply having less code.
When you're a junior engineer overdoing it like this on a small project can be a good way to practice new skills and see how they apply through a project's whole lifecycle.
Remember juniors have it tough in the employment market, so some of this could be due to RDD, so they can tack on SQL, ORM, managed vm infrastructure, on their resumes.
Are you sure that all this infrastructure is not, to them, the actual point of the project? Sometimes it’s fun to go way overboard on engineering for its own sake. I saw one guy who’d built an entire PLC-based control cabinet to automate a cat door. Necessary? No but that’s beside the point. :D
The reason they're doing that is because theyre going to be tested on that knowledge when finding employment. It's harder than ever to be full stack, but there's plenty of competition.
Very good article and I hope more people read it. Over my career of 15 years in software (data management), I have learned exactly that. One other thing that really helped me was something that I learned in my Theravada Buddhist upbringing: https://en.wikipedia.org/wiki/Kesamutti_Sutta
> The Kesamutti Sutta states (Pali expression in parentheses):[5]
Do not go upon what has been acquired by repeated hearing (anussava),
nor upon tradition (paramparā),
nor upon rumor (itikirā),
nor upon what is in a scripture (piṭaka-sampadāna)
nor upon surmise (takka-hetu),
nor upon an axiom (naya-hetu),
nor upon specious reasoning (ākāra-parivitakka),
nor upon a bias towards a notion that has been pondered over (diṭṭhi-nijjhān-akkh-antiyā),
nor upon another's seeming ability (bhabba-rūpatāya),
nor upon the consideration, The monk is our teacher (samaṇo no garū)
Kalamas, when you yourselves know: "These things are good; these things are not blamable; these things are praised by the wise; undertaken and observed, these things lead to benefit and happiness," enter on and abide in them.'
That advice is something that I found very useful in life even though I have become an atheist since I was in 8th-9th grade.
Even though what you've shared here resonates with me, after googling it I seem to have discovered that this particular translation is contested. The claim seems to be that someone distorted their translation to be more rationalistic.[0]
Which is a shame if true, because I sorely wanted to believe that the Buddha was this, um, enlightened.
> But also don't worry too hard about getting "tricked" or learning "the wrong thing".
Did I learn TDD when it was hip? Yes. Do I use TDD? No. But did TDD teach me how to write better code? Yes.
Same with languages I've learnt but not ended up using professionally. Everything teaches you something. You can't find a good middle ground without stepping a bit too far in both directions.
I think we all do a bit of TDD, just not the extreme kind. If you already have the code and now you're trying to extend it, thinking about how this is going to be done and writing a few tests around the usage makes sense. It also makes sense if you don't have the code but you do have a way to structure the code in your mind and you can figure out what parts you can build and test first.
So while it's not TDD in the pure sense (it's more like Test Assisted Development) it is leveraging the spirit of TDD.
Couldn't agree more. Learning bad things - not that TDD is bad, or anything, but over committing to it might be - is a huge part of understanding why certain approaches are better or worse than others. Although, I suppose 'making mistakes is the path to learning' is already conventional wisdom, so.
Sometimes. If the project/feature I'm working on lends itself to TDD, I use it. Generally speaking, all this guidelines and principles are good to know. They become a problem when people take them religiously. Ideologists are really a plague in our profession.
> Eventually the honeymoon will end and you'll learn that programming is frustrating and messy regardless of which Right Way people use, and that you can also make great software without doing it the Right Way. Over time you'll learn fifty other Right Ways and learn to mix and match them to the problem at hand.
My impression though from last few years is that nowadays many developers get stuck being Right Way Guys and are unable to broaden their knowledge and views. This is sad and I do not know the cause of that if it is true. My speculation is that it has something to do with too short attention spans nowadays to efficiently expand knowledge in combination with being to comfortable in their current positions. Or maybe something with too much incentives to only learn specific frameworks and not basic knowledge of how things work “under the hood”.
My guess is that professional developers are too concerned into getting into their new job next year. So they both don't have time to learn the lessons from this one (because they'll be out by the time those lessons hit) and they can't afford to not focus on the new great thing.
My 1¢ of advice: State is the enemy. Minimize state wherever you can.
This includes state as in your code, state as in how many things you need to hold in short term memory to do your job, state as in how many project specific details you need to remember, all of it. State is the enemy. If you can derive it from first principles, always try to do so.
I cannot stress enough how much you can reduce "how many things you need to hold in short term memory to do your job" by just keeping a notebook (or file, or wiki, or whatever works for you) and writing things down.
Some of these go beyond just advice for programmers. Everyone should reflect on the first point: most authors and essayists are read because they are good writers, not necessarily because they are experts on the subject matter.
Take walks!
Try different types of work. Learn about other job functions at your company. In big companies in particular, you may be doing things that just have to be corrected or worked around somewhere else, when you could make things easier for everyone.
The first item is also why it's good to be skeptical about things you learn on video sharing services like YouTube too. If you sound credible and present your ideas in a professional way, people will take them seriously regardless of how flawed they might be. In a world where a fair few 'essayists' have been exposed for just reading Wikipedia articles and Reddit posts, it's definitely good to try and not associate how people present their ideas with how accurate said ideas are.
I'd also expand on point 10 to add that talking to these people often gives you a better picture of what problems your software/dev work is trying to solve, and can help you identify pain points that you may not have noticed yourself. Remember that with a (very few) exceptions, software isn't written for the sake of it, it's written to solve problems.
Either way, nice list! Definitely has some useful advice there.
This comment just made me consider LLMs as similar to the essayists you mentioned - they read the "right" answer somewhere on the internet/during training and then can regurgitate it in a way that makes sense without consideration of how true it is in practice.
I'm such a fan of the debugging book[1] recommended in the article that I bought a bunch of copies to give out. I've given copies to friends, interns, data scientists and even executives, and everybody who's read it has appreciated it. The book has a small number of simple techniques that are great for solving problems in any large technical systems, so it's useful for almost everybody. It's also an easy and engaging read, with lots of "war stories" providing color and context for the otherwise-dry suggestions.
> People don't listen to me because I'm a good programmer, they listen to me because I'm a good writer.
I think this point extends beyond the idea of guarding ourselves while reading the contents of good writers; it's also about how we should approach our jobs. Being a good writer will most likely improve your skills in dealing with other people. As software developers, writing and communicating with others is crucial to our work.
I would also recommend beginners to write about the challenges they have encountered, their experiments, and their thought processes, among other things. If possible, they should write essays. This will prove to be a really useful skill later in their careers.
The one I have a hard time explaining well enough for new folks to get is: "It is not your job to write code."
We use code as a tool to solve problems. Code is the mechanism of achieving our goals, not the goal in and of itself. If we are coding just for code's sake, we'll deliver the wrong results. We need to be focused on solving problems, and if we aren't sure what problem our code is solving, we need to stop coding and figure that out.
Most advice about programming is about writing code, but we rarely ever consciously consider how to improve at reading code. One way to do that is to read more code.
If you read really good code, and I mean really read it, like a book, and absorb it, then you will improve so much.
This kind of improvement is the most impactful, because you also spend most of your time as a programmer reading code than writing new code.
Also, if you become good at reading code, then you don't need documentation.
Despite reading essays of other devs telling you how you should dev, have faith in yourself. Over time you'll develop your own proclivities, instincts, etc., and end up writing your own essays to the next generation.
People writing essays are not writing it from some impossible point of knowledge or privilege. They're just you in the future.
> People don't listen to me because I'm a good programmer, they listen to me because I'm a good writer. The same is true of pretty much everybody you'll read.
This is so important and so general. Even writers who make a lot of their real world experience like Nassim Taleb are still read because they are good writers. No one reads Jeff Bezos' letters to his shareholders, because he's not a good writer.
Code reviews are so impactful. Learning how to have others look at your code and provide feedback, and you looking at others and provide feedback is huge. Mixing in the junior devs into the mix, where they feel safe to ask what is going on here or why, is the perfect comment canary. Taking the journey from 'ugly, but acceptable' to polished only comes from feedback and looking at other's code.
I'm fortunate enough to have an office overlooking a small pond. When I'm frustrated I go to my window and stare at the pond for a while. When I'm really frustrated I walk down to the pond and stare at it for a while.
I also walk to lunch as often as I can (i.e. when it's not freezing or boiling outside). Highly recommend.
Before anything else, learn how to solve problems on your own. I know, we have this huge thing called the internet where everyone else has already solved every problem, but you really need to develop your own problem solving skills and looking up how other people did stuff won't help you do that.
[+] [-] zaptheimpaler|2 years ago|reply
It's frustrating and sad to see people do that. I was myself a "Right Way Guy" at the beginning of my programming for a few years, before I learned how much depth there is in CS besides junk like best practices and code style and how to focus on the only thing that matters - working code. They are often too convinced of their rightness.
[+] [-] akshatpradhan|2 years ago|reply
Imagine a committee commissioned to approve plans for a Nuclear Power Plant. But the committee spends all their time discussing the color of the bike shed that they want built nearby.
In your case, their focus on separate VMs for QA/Production, systemd deployments, templating system for a few strings, and an ORM for a few SQL queries, especially for a project with a limited user base (10 people) really exemplifies Bike-shedding.
They’re emphasizing minor, arguably unnecessary details rather than the core functionality or purpose of the project [2]. This usually occurs because these trivial aspects are easier to understand and discuss, especially for junior devs, which leads to increased involvement on minor details while the more meaningful parts of a project (which might be more challenging to address), are overlooked or given less attention.
IMO, a good leader knows how to strike a balance between the “Right Way” and avoiding the pitfalls of “Bike-shedding”.
[1] https://en.wikipedia.org/wiki/Law_of_triviality
[2] I would argue complete documentation of the meaningful parts of the project is not bike-shedding.
[+] [-] jorisd|2 years ago|reply
Many of those things you list really don't take too much time to do, like writing systemd units or using an ORM. But they really help when anyone needs to take a look at things in the future or someone else wants to contribute as well later on. Besides, they're easier to do when things are still fresh in the mind, and these kinds of chores rarely get done later on when a project has grown.
This being a hobby project may also be a reason why the other programmers want to do things right; they may get satisfaction and learn new things by doing it this way!
[+] [-] Verdex|2 years ago|reply
Something I missed at first [1] was the significance of an event that happens early in the movie. They need to buy a $50 router because their existing one is broken. They have an impromptu meeting where one of the characters gives suggestions on how they could try to fix the existing router. The suggestions are all half spoken before being answered: "Did you try the ..." : "yes"; "well , how about resetting the ..." : "I tried that too". Clearly they're basically reading each other's minds because of how well they know each other and how much time they spend with each other.
But then comes the 'punchline'. One character says 'yes' to buying the new router. The other response with "I need an 'aye'". Their side business apparently has very strict rules about what words they need to use for voting on decisions. It doesn't matter that they all know each other so well that they're finishing each other's sentences. It doesn't matter that this is a $50 router. And it doesn't matter that their income from this side business is inconsequential. The rules say that they need an 'aye'.
My own theory with "Right Way Guys" is that some people have been able to find a lot of success by leveraging the knowledge that's stored in the hivemind of society. They don't really know what they're doing when you consider what's going on inside their skull. But they have successfully copied success up till now. The plus side is that they're able to inherit successful methodologies that have survived over time without having to do all the hard work themselves. The down side is that they literally don't understand when they're in a scenario where it will lead to failure. [2]
[1] - I didn't think much of this until I watched the director commentary. Where they explicitly talk about how they intentionally setup this interaction to showcase how certain characters took the rules too seriously and which ones didn't take them seriously enough.
[2] - My theory on my theory is that this is also why so many people encourage others to join in their favored cargo cult practice (be it software development or anything else). Social behaviors may or may not work, but the more people you can convince to follow them the greater the chance that when they fail catastrophically and/or fatally they're failing for someone who isn't you.
[+] [-] saiya-jin|2 years ago|reply
Smart juniors know most if not all design patterns, read Mythical man month, and so on, and... is super eager to try new technologies, languages, frameworks and is literally running around with shiny new hammers desperately looking for anything resembling nails. And then they do some stupid decisions because they don't grok the power an optimized boring old DB can bring in.
Then comes a guy like me with 20 years of experience who has seen damn well how such projects end up 5-10 years down the line with half if not most of the original team gone, and cuts half of that crap out while keeping genuine added value, because we are not running kindergarten for devs who want to have fun at all costs all the time, we work for our business who pays us and expects good, stable and relatively quick deliveries, rest are details on our side. You can't be taken seriously by business if you behave like that, no matter how good your intentions are.
IMHE bleeding edge stuff and trying new things for the sake or avoiding boredom will consistently break more down the road than it will help fixing. We incorporate technologies which whole team can grok and be proficient in, not just some bored superstar. Build your CV elsewhere if you desperately want as many technology entries as possible, there are companies like that, and good for them. IMHO these folks anyway don't stay around for too long so full added value is even questionable, the grass is always greener elsewhere, at least till they get there. Could be boring for some, I call it seasoned (yet still endless amount of stuff to learn, but that's fine this won't change till my retirement).
[+] [-] Arainach|2 years ago|reply
Documentation is crucial. I have some fairly basic <300LOC projects including a bot and a web scraper that I currently cannot run because I didn't document them. The Raspberry Pi they were running on died and I need to do....something....to fix my headless virtual framebuffer and debug some cryptic errors that do not find productive search results.
If I had containerized or, at a minimum, documented my setup steps, I would not have this problem.
[+] [-] hardwaregeek|2 years ago|reply
[+] [-] motoxpro|2 years ago|reply
[+] [-] Buttons840|2 years ago|reply
In the end, I think you're right though. As long as the code is reliable, then the shortest code is the best code (within reason, don't start playing code golf). It takes an awfully good abstraction to beat simply having less code.
[+] [-] tdeck|2 years ago|reply
[+] [-] gosub100|2 years ago|reply
[+] [-] yodsanklai|2 years ago|reply
Maybe it's a case of known the rules so you can break them.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] taneq|2 years ago|reply
[+] [-] devwastaken|2 years ago|reply
[+] [-] rewmie|2 years ago|reply
[deleted]
[+] [-] programmertote|2 years ago|reply
> The Kesamutti Sutta states (Pali expression in parentheses):[5] Do not go upon what has been acquired by repeated hearing (anussava), nor upon tradition (paramparā), nor upon rumor (itikirā), nor upon what is in a scripture (piṭaka-sampadāna) nor upon surmise (takka-hetu), nor upon an axiom (naya-hetu), nor upon specious reasoning (ākāra-parivitakka), nor upon a bias towards a notion that has been pondered over (diṭṭhi-nijjhān-akkh-antiyā), nor upon another's seeming ability (bhabba-rūpatāya), nor upon the consideration, The monk is our teacher (samaṇo no garū) Kalamas, when you yourselves know: "These things are good; these things are not blamable; these things are praised by the wise; undertaken and observed, these things lead to benefit and happiness," enter on and abide in them.'
That advice is something that I found very useful in life even though I have become an atheist since I was in 8th-9th grade.
[+] [-] rvbissell|2 years ago|reply
Which is a shame if true, because I sorely wanted to believe that the Buddha was this, um, enlightened.
[0] https://fakebuddhaquotes.com/do-not-believe-in-anything-simp...
[+] [-] bmicraft|2 years ago|reply
[+] [-] matsemann|2 years ago|reply
Did I learn TDD when it was hip? Yes. Do I use TDD? No. But did TDD teach me how to write better code? Yes.
Same with languages I've learnt but not ended up using professionally. Everything teaches you something. You can't find a good middle ground without stepping a bit too far in both directions.
[+] [-] x86x87|2 years ago|reply
So while it's not TDD in the pure sense (it's more like Test Assisted Development) it is leveraging the spirit of TDD.
[+] [-] Forricide|2 years ago|reply
[+] [-] yodsanklai|2 years ago|reply
Sometimes. If the project/feature I'm working on lends itself to TDD, I use it. Generally speaking, all this guidelines and principles are good to know. They become a problem when people take them religiously. Ideologists are really a plague in our profession.
[+] [-] diarrhea|2 years ago|reply
This is beautiful. So short, so apt, so instantly relatable and palpable.
[+] [-] havkom|2 years ago|reply
> Eventually the honeymoon will end and you'll learn that programming is frustrating and messy regardless of which Right Way people use, and that you can also make great software without doing it the Right Way. Over time you'll learn fifty other Right Ways and learn to mix and match them to the problem at hand.
My impression though from last few years is that nowadays many developers get stuck being Right Way Guys and are unable to broaden their knowledge and views. This is sad and I do not know the cause of that if it is true. My speculation is that it has something to do with too short attention spans nowadays to efficiently expand knowledge in combination with being to comfortable in their current positions. Or maybe something with too much incentives to only learn specific frameworks and not basic knowledge of how things work “under the hood”.
[+] [-] marcosdumay|2 years ago|reply
That really impedes growth.
[+] [-] hiAndrewQuinn|2 years ago|reply
This includes state as in your code, state as in how many things you need to hold in short term memory to do your job, state as in how many project specific details you need to remember, all of it. State is the enemy. If you can derive it from first principles, always try to do so.
[+] [-] eschneider|2 years ago|reply
[+] [-] johngossman|2 years ago|reply
Take walks!
Try different types of work. Learn about other job functions at your company. In big companies in particular, you may be doing things that just have to be corrected or worked around somewhere else, when you could make things easier for everyone.
[+] [-] CM30|2 years ago|reply
I'd also expand on point 10 to add that talking to these people often gives you a better picture of what problems your software/dev work is trying to solve, and can help you identify pain points that you may not have noticed yourself. Remember that with a (very few) exceptions, software isn't written for the sake of it, it's written to solve problems.
Either way, nice list! Definitely has some useful advice there.
[+] [-] I_Am_Nous|2 years ago|reply
[+] [-] tikhonj|2 years ago|reply
[1]: https://debuggingrules.com/
[+] [-] DevAbdul|2 years ago|reply
[+] [-] kugurerdem|2 years ago|reply
I think this point extends beyond the idea of guarding ourselves while reading the contents of good writers; it's also about how we should approach our jobs. Being a good writer will most likely improve your skills in dealing with other people. As software developers, writing and communicating with others is crucial to our work.
I would also recommend beginners to write about the challenges they have encountered, their experiments, and their thought processes, among other things. If possible, they should write essays. This will prove to be a really useful skill later in their careers.
[+] [-] codingdave|2 years ago|reply
We use code as a tool to solve problems. Code is the mechanism of achieving our goals, not the goal in and of itself. If we are coding just for code's sake, we'll deliver the wrong results. We need to be focused on solving problems, and if we aren't sure what problem our code is solving, we need to stop coding and figure that out.
[+] [-] asimpletune|2 years ago|reply
If you read really good code, and I mean really read it, like a book, and absorb it, then you will improve so much.
This kind of improvement is the most impactful, because you also spend most of your time as a programmer reading code than writing new code.
Also, if you become good at reading code, then you don't need documentation.
[+] [-] sevagh|2 years ago|reply
People writing essays are not writing it from some impossible point of knowledge or privilege. They're just you in the future.
[+] [-] amadeuspagel|2 years ago|reply
This is so important and so general. Even writers who make a lot of their real world experience like Nassim Taleb are still read because they are good writers. No one reads Jeff Bezos' letters to his shareholders, because he's not a good writer.
[+] [-] heelix|2 years ago|reply
[+] [-] salgorithm|2 years ago|reply
[+] [-] neoromantique|2 years ago|reply
[deleted]
[+] [-] thedanbob|2 years ago|reply
I'm fortunate enough to have an office overlooking a small pond. When I'm frustrated I go to my window and stare at the pond for a while. When I'm really frustrated I walk down to the pond and stare at it for a while.
I also walk to lunch as often as I can (i.e. when it's not freezing or boiling outside). Highly recommend.
[+] [-] happytiger|2 years ago|reply
Ok, now I’m listening.
Also, #8 is the best long term advice for programmers. Walk.
[+] [-] HumblyTossed|2 years ago|reply
[+] [-] billy99k|2 years ago|reply
[+] [-] nottorp|2 years ago|reply
That goes for all those talking heads on youtube too btw. They're not necessarily right, but they're good speakers/actors.