6 ms·

Ask HN: Top rules as a good-developer to stay on top of your game

51 points by samblr 10y ago

edit: Although I originally intended this question to full stack web development - answers from any domain developers are welcome. (Minor changes to sentence) Full-stack / web app development have a lot of moving pieces and these evolve at amazing speeds. As a developer/startup how do you stay on top of your game with these evolving pieces ? Im new to web development and looking for top 5 rules from battle-hardened developers, mainly, how do you keep evolving products-teams-yourself ?

trcollinson 10y ago
I would suggest a three part method to success. First, know what you do know and don't chase after everything you don't know. If you are good at php, use it. If you understand rails, use it. If you are a master of all things RDBMS, use one. When you are looking to tackle a problem, don't look for a new technology, language, or paradigm to solve the problem. Use what you already know, and solve the problem. Second, solve the problem. Also, don't pick a technology and then try to shoe horn that into the solution. In other words, when you have a new project, or an existing project that needs improvement, don't say, "Well I am going to need a, b, c, and d because every good project needs those!" Instead say, "What is the problem I am trying to solve? How do I define the problem? What value am I bringing?" Then find technologies and solutions to fit into the answers to those questions. Finally, learn new things incrementally. For example, maybe you are working on a web project and need a good mobile first css framework (due to the answers you received from the questions in the second part above). You always use Bootstrap. You add bootstrap into the project (because you know bootstrap, see the first part above). You've never used Sass but you'd like to add that. This might be the right time to add it to your skill set and this project. Notice how you didn't add a whole new css framework, a whole new application framework, a whole new language, a new server technology, a new javascript framework... you added one new thing incrementally. You can do that as often as it makes sense. But never more often.
- pawanpe 10y ago
  I second this process. I follow little similar which is working well for me
- spikej 10y ago
  I agree. Every project (personal or otherwise) is a chance to try out one new thing -- it might even be a deep dive into using previously unused features in the library/framework that you've not used before
- itake 10y ago
  I think this makes sense if you are trying to build skills to start a company yourself, but I think if you want to ride the pay curve, you need to be more agile when it comes to learning new tech. It is a fact that php devs earn less than RoR engineers. If you want to stay at the top of the pay curve, you need to stay up to date with the latest 'sexy.'
  - Kaizyn 10y ago
    Are you familiar with how compound interest works? Using this strategy, you may spend the first 2-5 years building up a broad but solid baseline of skills. After that, the amount of learning required to keep up with all the fads in technology would be very manageable by comparison.
  - trcollinson 10y ago
    I am going to respectfully have to call you out on this one. First off, where is this fact that php devs earn less than RoR engineers? I am sure there was some who earn less and some who earn more. The point though it that if you are aligning yourself on the latest technology, you will absolutely always lose in the long run. I would say I am in the top 5% of engineers by salary in my area. I never lead out with the language or framework or cool new 'sexy' technology that I think a business should/could/has to use. When looking for employment I never even worry about what the company is currently using. I literally only worry about aligning myself with their business objectives. What are the problems they are facing? How can they decrease costs or, often more importantly, increase revenue? Why do they need me and how can I solve their problems starting immediately? Now, you might say, well then you won't get hired on everywhere you apply to. Absolutely! And thank goodness. If I walk into an interview and all the current employees can talk about is the finer parts of minutia within the latest build of Rails, I would rather not work with them. If all I can be asked is how many ways you can concatenate a string in .Net and an example of when to use each, again, I will pass on that company. (yes, I have been asked exactly that question, and there are more ways than you think). Why would I pass? Well they sure as hell aren't aligning themselves with the needs of their business, how am I going to? Trust me, if you would like to stay on the top of the pay curve, align yourself with business objectives, particularly those which align with money. Don't worry about the 'new sexy'.
- Kaizyn 10y ago
  At first, I was afraid you were giving away the game on churning technology. But then I realised the sad thing is that no one will probably follow your advice, even though this is the best answer to this question.
- atmosx 10y ago
  Great tips to claim back sanity in an ever-growing dynamic environment such as IT.
tmaly 10y ago
learn tricks, tips, etc on how to write code that is easy to understand and maintain. It is said that we spend 10 times as long reading code as we do writing code. If you can optimize for that, it saves lots of effort over the long term.
- ThrustVectoring 10y ago
  Yup. If I'm working with code I can understand, making changes takes very little time. If I'm working with code I don't understand, I might be able to hack something together that makes things even harder to understand. Probably the best bet is to spend however long it takes to dive into it, and possibly rage-refactor if it's too much to dig into without being the person who wrote it.
ebbv 10y ago
The short answer is spend some (not all) of your free time on learning skills and self improvement. Over the last six years I've always tried to have side projects going, I have volunteered to help other people's projects and I have picked up a lot of skills from those. I also volunteered to attend training and read books that I might not have in the past.
dmessing 10y ago
Look at open source code. I think it is just as important to review well written code as it is to practice writing code.
sergiotapia 10y ago
Going to be a bit unpopular here, but what the hell. To be a great software developer you need to work on pet projects for yourself and for others. Some people do the 9-to-5 and that's fine. But those are going to be your median developers. Not your great developers. Nothing wrong with that. Great software developers are great because they sharpen that edge for fun. They straight up love writing code. When you work on pet projects you research new tools, new ways of doing things, and broaden your horizons. You open source stuff, forcing you to write clean code with proper documentation. That _directly_ influences how you write code for your job. That knowledge applies in strange and unexpected ways. In my experience you end up using a lot of the new stuff you pulled in through your escapades. You want to be a great software developer? Write open source code. Read open source code.
- traviswingo 10y ago
  I second this. I learn a lot at my 9-5, but I learn much more building small side projects where I have to do every piece of it myself, rather than just my part and off-put it onto the next team. Additionally, I've learned more than I can credit from simply reading open-source project code. You'd be surprised what weird little tricks you'll find in there.
- wlievens 10y ago
  I find that on pet projects I almost never learn new tools. I tend to have an idea that I want to try out, and I use the tech I know to get there quickly. It feels a bit sad, I must admit.
  - csallen 10y ago
    Interesting, I've had the exact opposite experience. When I'm working for someone else, I feel like I need to stick to the tools I know. But when I'm working on my own project, I have an itch to try out the latest and greatest thing, even if it's irresponsible to do so and will only slow me down.
- falcolas 10y ago
  You're perfectly capable of being a mediocre (or terrible) developer while writing code from the time you wake up to the time to go to bed. The way to actually get better (at anything) is to create a feedback loop and focus on the bits and pieces which matter. Ask a professional musician how they got better, and you won't hear them say "by playing the piano for 16 hours a day, every day". They'll say by doing focused practicing. And that can be done in anywhere between 2 and 6 hours a day. Even at your day job... You want to be a truly useful software developer? Expand your knowledge beyond software development by doing more than developing software.
falcolas 10y ago
Learn the concepts behind the technology. If you understand MVC, you can pick up React/Flux. If you understand callbacks, you can pick up promises. If you understand process isolation, you can pick up Docker. If you can install a program manually, you can pick up Chef/Ansible/Puppet. If you understand the practical limitations of memory, disk and the network, you can grok why MySQL, PostgreSQL, Mongo... all have the strengths and weaknesses they do. And so on. The downside is that you'll end up taking a look at the hot new technologies and shake your head a bit as you see the same concepts being reborn again and again, frequently with the same lessons to be learned.
aaronbrethorst 10y ago
The best developers I've ever worked with are the ones who are insatiably curious and relentlessly pragmatic. They always want to understand how and why things work the way they do, but they also understand the need to ship.
x0x0 10y ago
I think you need to be more specific. I don't think, except with a handful of exceptions for really stellar individuals, that there are good developers. Rather, there are good developers for a situation. imo, the things that make you successful in a google or apple vs in a small startup vs a consultant vs a one-person company are wildly different. Which are you interested in?
Rabei 10y ago
Be good at learning I don't mean technical stuff only, but the entire process of software development is to automate knowledge. You can't automate knowledge that you do not have.
fapjacks 10y ago
ABC: Always Be Coding.
dmuth 10y ago
In addition to having side projects going, don't hesitate to put them up on GitHub. That's a great way to show off your skills. And these projects don't have to be huge, even if they are small utilities or apps that scratch a specific itch, that's also good to show off, especially if it's for a problem which has not been solved before. If you're especially lucky, you may wind up with an employer who lets you open source some of what you write. :-)
mooneater 10y ago
My main tips: 1) Read a lot about what is out there. Reading viewpoints helps prioritize what you want to learn next. Talk to opinionated, passionate people and understand why they hold strong views. 2) Experiment with things well outside your comfort zone. Eg., a language that you may never get deep into, but can give you a new perspective. 3) Figure out what NOT to learn. There are so many new things and the rate is increasing. I feel I cannot afford to spend a long time learning the wrong things. So for example I focus on python instead of python+c#, postgres instead of postgres+mysql, linux instead of linux+osx. Spreading me less thin. But to do this you have to know why you choose X over Y, the reading and experimenting infom you for this. 4) Learning "technologies" is not enough imo, you need to couple that with theory to produce really powerful systems. Machine Learning, Crypto, Controls, Discrete, whatever you are interested in. You can learn this alone, but sometimes a course or two is the best way to beef up your theory. 5) I've come to think about digital systems having an "anatomy" similar to the human body. Different components are like various organs. Building complete, balanced systems requires understanding all the various types of organs. Assume you have blind spots, and seek to discover and master the organs (types of components) that are least familiar to you. You do this by inspecting other systems and seeing how they are composed and how that differs from how you compose your systems. Very interesting to see what others say about this.
- imh 10y ago
  >4) Learning "technologies" is not enough imo, you need to couple that with theory to produce really powerful systems. This is HUGE. I'm able to keep up to speed and learn more ML and stats comparatively quickly because I have strong applied math foundations (from a physics and applied math background) and have learned the theory behind the stats (from lots of hard work and self study). It fits into the "work smarter, not just harder" bucket. If you can learn 1+1=2, 2+1=3, 3+1=4,... that's a ton of shit to memorize. But learning how x+1 works for all x, you only have to learn one thing (kinda). It's a rough analogy, but that's how I think of it.
- nickbail3y 10y ago
  I think these are all really good tips. I'd like to tack onto number 3 though: 3a) Don't try to learn everything. Being a jack of all trades and a master of none isn't the solution. Be able to write good code / thoroughly utilize the technologies and frameworks that you DO know. Then progress from there.
cdnsteve 10y ago
Work with a talented team. You learn things you would never learn otherwise as a solo dev. The human interaction side, writing more universal code. You'd be amazed how much code makes complete sense to the author but isn't clear to team mates. Learning new things on your own is good. Having a good employer that encourages on the job learning is very important. Whatever you use this year might be obsolete the next. Action Script anyone? Don't pressure yourself to work all the time. Maintain a healthy balance. Eventually I think every developer goes through a period of being overwhelmed. You can't learn it all, even if you work 15 hour days. Learning is a journey so pace yourself.
NetStrikeForce 10y ago
Define "stay on of your game" first :) Does it mean "keep or increase your value for your company"? If that's the case: learn to understand the business. Try to walk in your CEO's shoes when making decisions. It'll make your way better. You might learn a new technology and want to apply, but does it play well with your current infrastructure? is it cheap to maintain? will the company be dependent on your existence to fix things? No technology, programming language or framework would be more valuable than understanding the business. If it means "know about the latest buzzwords and newest programming languages and frameworks" then I don't know, reading HN to spot the trends maybe? :) By the way, a golden rule of the so-called battle-hardened professionals is to let someone else fight the battles and learn from their results. In other words, don't be the first to deploy the new buzzword in production :)
torte 10y ago
To actually answer your question about "how to stay on top of your game": Don't try to keep up with all the new shiny things coming around. Focus on a few things you want to learn and learn them deeply. This will make it easier to adapt new things later in case you MUST learn something.
Jugurtha 10y ago
Here's a paper that might be of value: http://projects.ict.usc.edu/itw/gel/EricssonDeliberatePracticePR93.PDF http://projects.ict.usc.edu/itw/gel/EricssonDeliberatePracti...
hannele 10y ago
Find excuses to learn things outside your comfort zone, at your work or through pet projects. The pet project can be easy, as long as you have the time and motivation - pick a tech and make a small hacky thing. (I must admit to being an unrepentant procrastinator so this is advice I have rarely followed myself.) The work route can also be rewarding though, given the appropriate work culture. I haven't found it too hard to take the time to learn about a thing that is blocking my team, and in my case I've gradually built up my knowledge of infrastructure and deployment practices where previously I'd mainly only written code. When you run into a bug, make sure you dive down into _why_ it broke in the first place, as well as what. This will help you avoid [cargo-culting][1] and can also give you some [pretty fun stories][2]. [1]: https://en.wikipedia.org/wiki/Cargo_cult_programming [2]: https://medium.engineering/the-curious-case-of-disappearing-polish-s-fa398313d4df

51 points by samblr 10y ago

trcollinson 10y ago

I would suggest a three part method to success. First, know what you do know and don't chase after everything you don't know. If you are good at php, use it. If you understand rails, use it. If you are a master of all things RDBMS, use one. When you are looking to tackle a problem, don't look for a new technology, language, or paradigm to solve the problem. Use what you already know, and solve the problem. Second, solve the problem. Also, don't pick a technology and then try to shoe horn that into the solution. In other words, when you have a new project, or an existing project that needs improvement, don't say, "Well I am going to need a, b, c, and d because every good project needs those!" Instead say, "What is the problem I am trying to solve? How do I define the problem? What value am I bringing?" Then find technologies and solutions to fit into the answers to those questions. Finally, learn new things incrementally. For example, maybe you are working on a web project and need a good mobile first css framework (due to the answers you received from the questions in the second part above). You always use Bootstrap. You add bootstrap into the project (because you know bootstrap, see the first part above). You've never used Sass but you'd like to add that. This might be the right time to add it to your skill set and this project. Notice how you didn't add a whole new css framework, a whole new application framework, a whole new language, a new server technology, a new javascript framework... you added one new thing incrementally. You can do that as often as it makes sense. But never more often.

pawanpe 10y ago
I second this process. I follow little similar which is working well for me
spikej 10y ago
I agree. Every project (personal or otherwise) is a chance to try out one new thing -- it might even be a deep dive into using previously unused features in the library/framework that you've not used before
itake 10y ago
I think this makes sense if you are trying to build skills to start a company yourself, but I think if you want to ride the pay curve, you need to be more agile when it comes to learning new tech. It is a fact that php devs earn less than RoR engineers. If you want to stay at the top of the pay curve, you need to stay up to date with the latest 'sexy.'
- Kaizyn 10y ago
  Are you familiar with how compound interest works? Using this strategy, you may spend the first 2-5 years building up a broad but solid baseline of skills. After that, the amount of learning required to keep up with all the fads in technology would be very manageable by comparison.
- trcollinson 10y ago
  I am going to respectfully have to call you out on this one. First off, where is this fact that php devs earn less than RoR engineers? I am sure there was some who earn less and some who earn more. The point though it that if you are aligning yourself on the latest technology, you will absolutely always lose in the long run. I would say I am in the top 5% of engineers by salary in my area. I never lead out with the language or framework or cool new 'sexy' technology that I think a business should/could/has to use. When looking for employment I never even worry about what the company is currently using. I literally only worry about aligning myself with their business objectives. What are the problems they are facing? How can they decrease costs or, often more importantly, increase revenue? Why do they need me and how can I solve their problems starting immediately? Now, you might say, well then you won't get hired on everywhere you apply to. Absolutely! And thank goodness. If I walk into an interview and all the current employees can talk about is the finer parts of minutia within the latest build of Rails, I would rather not work with them. If all I can be asked is how many ways you can concatenate a string in .Net and an example of when to use each, again, I will pass on that company. (yes, I have been asked exactly that question, and there are more ways than you think). Why would I pass? Well they sure as hell aren't aligning themselves with the needs of their business, how am I going to? Trust me, if you would like to stay on the top of the pay curve, align yourself with business objectives, particularly those which align with money. Don't worry about the 'new sexy'.
Kaizyn 10y ago
At first, I was afraid you were giving away the game on churning technology. But then I realised the sad thing is that no one will probably follow your advice, even though this is the best answer to this question.
atmosx 10y ago
Great tips to claim back sanity in an ever-growing dynamic environment such as IT.

tmaly 10y ago

learn tricks, tips, etc on how to write code that is easy to understand and maintain. It is said that we spend 10 times as long reading code as we do writing code. If you can optimize for that, it saves lots of effort over the long term.

ThrustVectoring 10y ago
Yup. If I'm working with code I can understand, making changes takes very little time. If I'm working with code I don't understand, I might be able to hack something together that makes things even harder to understand. Probably the best bet is to spend however long it takes to dive into it, and possibly rage-refactor if it's too much to dig into without being the person who wrote it.

ebbv 10y ago

The short answer is spend some (not all) of your free time on learning skills and self improvement. Over the last six years I've always tried to have side projects going, I have volunteered to help other people's projects and I have picked up a lot of skills from those. I also volunteered to attend training and read books that I might not have in the past.

dmessing 10y ago

Look at open source code. I think it is just as important to review well written code as it is to practice writing code.

sergiotapia 10y ago

Going to be a bit unpopular here, but what the hell. To be a great software developer you need to work on pet projects for yourself and for others. Some people do the 9-to-5 and that's fine. But those are going to be your median developers. Not your great developers. Nothing wrong with that. Great software developers are great because they sharpen that edge for fun. They straight up love writing code. When you work on pet projects you research new tools, new ways of doing things, and broaden your horizons. You open source stuff, forcing you to write clean code with proper documentation. That _directly_ influences how you write code for your job. That knowledge applies in strange and unexpected ways. In my experience you end up using a lot of the new stuff you pulled in through your escapades. You want to be a great software developer? Write open source code. Read open source code.

traviswingo 10y ago
I second this. I learn a lot at my 9-5, but I learn much more building small side projects where I have to do every piece of it myself, rather than just my part and off-put it onto the next team. Additionally, I've learned more than I can credit from simply reading open-source project code. You'd be surprised what weird little tricks you'll find in there.
wlievens 10y ago
I find that on pet projects I almost never learn new tools. I tend to have an idea that I want to try out, and I use the tech I know to get there quickly. It feels a bit sad, I must admit.
- csallen 10y ago
  Interesting, I've had the exact opposite experience. When I'm working for someone else, I feel like I need to stick to the tools I know. But when I'm working on my own project, I have an itch to try out the latest and greatest thing, even if it's irresponsible to do so and will only slow me down.
falcolas 10y ago
You're perfectly capable of being a mediocre (or terrible) developer while writing code from the time you wake up to the time to go to bed. The way to actually get better (at anything) is to create a feedback loop and focus on the bits and pieces which matter. Ask a professional musician how they got better, and you won't hear them say "by playing the piano for 16 hours a day, every day". They'll say by doing focused practicing. And that can be done in anywhere between 2 and 6 hours a day. Even at your day job... You want to be a truly useful software developer? Expand your knowledge beyond software development by doing more than developing software.

falcolas 10y ago

Learn the concepts behind the technology. If you understand MVC, you can pick up React/Flux. If you understand callbacks, you can pick up promises. If you understand process isolation, you can pick up Docker. If you can install a program manually, you can pick up Chef/Ansible/Puppet. If you understand the practical limitations of memory, disk and the network, you can grok why MySQL, PostgreSQL, Mongo... all have the strengths and weaknesses they do. And so on. The downside is that you'll end up taking a look at the hot new technologies and shake your head a bit as you see the same concepts being reborn again and again, frequently with the same lessons to be learned.

aaronbrethorst 10y ago

The best developers I've ever worked with are the ones who are insatiably curious and relentlessly pragmatic. They always want to understand how and why things work the way they do, but they also understand the need to ship.

x0x0 10y ago

I think you need to be more specific. I don't think, except with a handful of exceptions for really stellar individuals, that there are good developers. Rather, there are good developers for a situation. imo, the things that make you successful in a google or apple vs in a small startup vs a consultant vs a one-person company are wildly different. Which are you interested in?

Rabei 10y ago

Be good at learning I don't mean technical stuff only, but the entire process of software development is to automate knowledge. You can't automate knowledge that you do not have.

fapjacks 10y ago

ABC: Always Be Coding.

dmuth 10y ago

In addition to having side projects going, don't hesitate to put them up on GitHub. That's a great way to show off your skills. And these projects don't have to be huge, even if they are small utilities or apps that scratch a specific itch, that's also good to show off, especially if it's for a problem which has not been solved before. If you're especially lucky, you may wind up with an employer who lets you open source some of what you write. :-)

mooneater 10y ago

My main tips: 1) Read a lot about what is out there. Reading viewpoints helps prioritize what you want to learn next. Talk to opinionated, passionate people and understand why they hold strong views. 2) Experiment with things well outside your comfort zone. Eg., a language that you may never get deep into, but can give you a new perspective. 3) Figure out what NOT to learn. There are so many new things and the rate is increasing. I feel I cannot afford to spend a long time learning the wrong things. So for example I focus on python instead of python+c#, postgres instead of postgres+mysql, linux instead of linux+osx. Spreading me less thin. But to do this you have to know why you choose X over Y, the reading and experimenting infom you for this. 4) Learning "technologies" is not enough imo, you need to couple that with theory to produce really powerful systems. Machine Learning, Crypto, Controls, Discrete, whatever you are interested in. You can learn this alone, but sometimes a course or two is the best way to beef up your theory. 5) I've come to think about digital systems having an "anatomy" similar to the human body. Different components are like various organs. Building complete, balanced systems requires understanding all the various types of organs. Assume you have blind spots, and seek to discover and master the organs (types of components) that are least familiar to you. You do this by inspecting other systems and seeing how they are composed and how that differs from how you compose your systems. Very interesting to see what others say about this.

imh 10y ago
>4) Learning "technologies" is not enough imo, you need to couple that with theory to produce really powerful systems. This is HUGE. I'm able to keep up to speed and learn more ML and stats comparatively quickly because I have strong applied math foundations (from a physics and applied math background) and have learned the theory behind the stats (from lots of hard work and self study). It fits into the "work smarter, not just harder" bucket. If you can learn 1+1=2, 2+1=3, 3+1=4,... that's a ton of shit to memorize. But learning how x+1 works for all x, you only have to learn one thing (kinda). It's a rough analogy, but that's how I think of it.
nickbail3y 10y ago
I think these are all really good tips. I'd like to tack onto number 3 though: 3a) Don't try to learn everything. Being a jack of all trades and a master of none isn't the solution. Be able to write good code / thoroughly utilize the technologies and frameworks that you DO know. Then progress from there.

cdnsteve 10y ago

Work with a talented team. You learn things you would never learn otherwise as a solo dev. The human interaction side, writing more universal code. You'd be amazed how much code makes complete sense to the author but isn't clear to team mates. Learning new things on your own is good. Having a good employer that encourages on the job learning is very important. Whatever you use this year might be obsolete the next. Action Script anyone? Don't pressure yourself to work all the time. Maintain a healthy balance. Eventually I think every developer goes through a period of being overwhelmed. You can't learn it all, even if you work 15 hour days. Learning is a journey so pace yourself.

NetStrikeForce 10y ago

Define "stay on of your game" first :) Does it mean "keep or increase your value for your company"? If that's the case: learn to understand the business. Try to walk in your CEO's shoes when making decisions. It'll make your way better. You might learn a new technology and want to apply, but does it play well with your current infrastructure? is it cheap to maintain? will the company be dependent on your existence to fix things? No technology, programming language or framework would be more valuable than understanding the business. If it means "know about the latest buzzwords and newest programming languages and frameworks" then I don't know, reading HN to spot the trends maybe? :) By the way, a golden rule of the so-called battle-hardened professionals is to let someone else fight the battles and learn from their results. In other words, don't be the first to deploy the new buzzword in production :)

torte 10y ago

To actually answer your question about "how to stay on top of your game": Don't try to keep up with all the new shiny things coming around. Focus on a few things you want to learn and learn them deeply. This will make it easier to adapt new things later in case you MUST learn something.

Jugurtha 10y ago

Here's a paper that might be of value: http://projects.ict.usc.edu/itw/gel/EricssonDeliberatePracticePR93.PDF http://projects.ict.usc.edu/itw/gel/EricssonDeliberatePracti...

hannele 10y ago

Find excuses to learn things outside your comfort zone, at your work or through pet projects. The pet project can be easy, as long as you have the time and motivation - pick a tech and make a small hacky thing. (I must admit to being an unrepentant procrastinator so this is advice I have rarely followed myself.) The work route can also be rewarding though, given the appropriate work culture. I haven't found it too hard to take the time to learn about a thing that is blocking my team, and in my case I've gradually built up my knowledge of infrastructure and deployment practices where previously I'd mainly only written code. When you run into a bug, make sure you dive down into _why_ it broke in the first place, as well as what. This will help you avoid [cargo-culting][1] and can also give you some [pretty fun stories][2]. [1]: https://en.wikipedia.org/wiki/Cargo_cult_programming [2]: https://medium.engineering/the-curious-case-of-disappearing-polish-s-fa398313d4df