## being productive - optimizing workspace fonts are VERY important, since they're staring at code all day ## exploring Sight reading: download the source code for the software, and start exploring. How do you know where to look? What tricks do you use to find your way around a significant body of code? ## finding a mentor Always try to be the worst musician in the band. Find a "be the worst" situation for yourself. Ask old-timers to review your code and make suggestions that would make it more idiomatically correct. A mentor is someone you can trust enough to ask, "What should be different about me as a professional?" Not only do you create a personal attachment and responsibility to your mentor, but the reverse happens as well. If my role in a relationship is to help someone, I become invested in that person's success. Nobody has to explicitly ask someone to be their mentor. Your mentor may not even know they are serving that role for you. Think of the person in your field whom you admire most. List the ten most important attributes of this role model. Choose the attributes that are the reason why you have chosen this person to be your role model. Rank those qualities in order of importance. You have now created and distilled a list of attributes that you find admirable and important. These are the ways in which you should strive to emulate your chosen role model. For each item on the list, imagine how your role model would rate you on a scale of 1 to 10 Subtract your rating in each row from the importance level you gave it. That gives you a final priority score He was just a high-school kid. But, he was already playing gigs, substituting for Little Rock's most respected jazz pianists. Chris was pretty good - especially for his age - but he wasn't that good. It didn't take me long to understand what was happening. When the band we were watching took a set break, Chris would break mid-sentence and just walk away from me to go talk to the band members. He was pushy as hell and would always ask if he could sit in with the band, no matter how inappropriate it seemed to me. He would also ask the musicians for lessons, which meant that he would go to their houses, listen to music, and chat about jazz improvisation with them. I've seen the same pattern in people I've met in classical music, the American Tibetan Buddhist community, software development. Really good people won't mind if you want to know them. People like to be appreciated, and they like to talk about the topics they are passionate about. The fact that they are the professional or the guru or the leader or the renowned author doesn't change that they're human and like to interact with other humans. The gurus are the supernodes in the social and professional network. All it takes to make the connection is a little less humility. ## learning by writing and teaching Martin Fowler said that whenever he wants to really learn about something, he writes about it. To really learn something, try teaching it to someone else. There's no better way to crystallize your understanding of something than to force yourself to express it to someone else so that they can understand it. We internally work through the reasons why one analogy seems to work but doesn't and another analogy would seem not to work but does. When you teach, you have to answer questions that may have never occurred to you. Helping someone is a job you can't be laid off from. ## learning elsewhere the best programmers are the ones who have hobbies and interests that are NOT within the domain of software development - this allows them to be much more [creative], meaning they can frame better logic ## learning from others How do others strategically use variable, function, and structure naming? There is no hidden source code for a painting or a piece of music. If you can hear the music or see the piece of art, you can learn from it. As you look at this code with a critical eye, you will start to develop your own tastes, just as you would for music, art, or literature. Various styles and devices will amuse you, amaze you, anger you, and (I hope) challenge you. You will learn more about what already exists. Pick a project, and read it like a book. Make notes. Outline the good and the bad. Write a critique, and publish it. Find at least one trick or pattern that you can use from it. Find at least one bad thing that you observed that you will add to your "What not to do" checklist. You should read good code. You have to actively copy, widely and unashamedly. This applies to a lot of things, of course. Hunter S. Thompson didn't just read good books; he typed out Hemingway and Fitzgerald. Copying builds muscle memory. You get a feel for the nuance and form of the original - the kind of detail that's lost in a quick scan. ## Learning NOTE: the content references and merges w/ AL Memory ## loving programming Programming: I was addicted, but in a good way. My drive to create had been ignited in much the same way that it had when I started writing classical music or playing improvisational jazz. I was obsessed with learning anything and everything I could. I wasn't in this for a new career. In fact, many of my musician friends thought of it as an irresponsible distraction from my actual career. I was in it because I couldn't not be. This was the difference between me and my overeducated, underperforming colleagues at work. Passion. The greats in various fields, this same pattern of addictive, passionate behavior surfaces. Jazz saxophone great John Coltrane reportedly practiced so much that his lips would bleed. ## practicing When you practice music, it shouldn't sound good. If you always sound good during practice sessions, it means you're not stretching your limits. That's what practice is for. Can you imagine a professional musician getting onstage and replicating the gibberish from my university's practice rooms? It wouldn't be tolerated. Musicians are paid to perform in public - not to practice. I started experimenting with programming exercises modeled after my musical practice sessions. Rule number one was that the software I was developing couldn't be something I wanted to use. I didn't want to cut corners, rushing to an end goal. So, I wrote software that wasn't useful. I cut no corners but was frustrated to find that a lot of the ideas I had while practicing weren't working. Though I was trying to do as good a job as possible, the designs and code I was creating weren't as elegant as I had hoped they'd be. Looking back on it now, I see that the awkward feeling I got from these experiences was a good sign. My code wasn't completely devoid of brilliant moments. But I was stretching my mental muscles and building my coding chops. Practice at your limits. Got any favorite pieces of open source software? How about trying to add a feature? Go look at the to-do list for a piece of software you'd like to practice with, and give yourself a constrained amount of time to implement the new feature. This is an exercise you can practice often and in short periods of time. You don't actually have to implement the feature. Just use it as a starting point. The real goal is to understand what you're looking at as quickly as possible. Be sure to vary the software you work with. Try different types of software in different styles and languages. Take note of issues that make it easier or harder for you to find your way around. What patterns are you developing that help you work through the code? What virtual bread crumbs do you leave for yourself to help you navigate as you move up and down the call stack of a complex piece of functionality? A great way to sharpen the mind and improve your improvisational coding skills is to practice with self-imposed constraints. Pick a simple program, and try to write it with these constraints. My favorite exercise is to write a program that prints the lyrics to the tired old song "99 Bottles of Beer on the Wall." How could you write such a program without doing any variable assignments? How fast can you code this program? How about practicing small, difficult problems with a timer? Code Kata, which are small, thought-provoking exercises that programmers can do in the language of their choice. Each kata emphasizes a specific technique or thought process, providing a concrete flexing of one's mental muscles. Work through all twenty-one kata. Listening to music, therefore, is not a passive activity for a jazz musician. It is study. Furthermore, the ability to understand what you're hearing is a skill that you develop over time. Studying the work of masters is an essential part of becoming a master. ## practicing with time constraints and the present "Work expands so as to fill the time available for its completion." The sad thing is that even when you don't want it to be this way, you can fall into the trap, especially when there are tasks you don't really want to do. In the case of a weekend coding race, you don't have time to put tasks off, so you don't. You can't delay making a decision, so you don't. You can't avoid the boring work, and you know that you have to do it so quickly that nothing can get too boring. A sense of urgency, even if manufactured, is enough to easily double or triple your productivity. Try it, and you'll see. You can do it faster. You can do it now. You can get it done instead of talking about getting it done. If you treat your projects like a race, you'll get to the end a lot faster. Keeping your mind focused on the present will get you further toward your goals than keeping your mind focused on the goal. If you're always walking around with your head in the clouds, You'll always be waiting for the big one while ignoring the little things that happen every day. What if you tried to do the boring stuff perfectly? Martin renamed forty-hour workweek to "eight-hour burn." The idea is that you should work so relentlessly that there is no way that you could continue longer than eight hours. When you have too much time to work, your work time reduces significantly in perceived value. If you have seventy hours available, each hour is less precious to you than when you have forty hours available. Eight-hour burn places a constraint on you and gives you a strategy for dealing with that constraint. You get to work and think, I've only got eight hours! Go, go, go! If you work intensely every day, you'll find that the work doesn't follow you home. Not only are you deliberately stopping yourself from working after-hours, but your mind will actually allow you to stop working after-hours. Chris would actually plan down to how he was going to use the fifteen minutes between classes to fit in practice routines that could be done quickly. ## prototyping A prototype is worth a thousand meetings - Mike Davidson ## Staying Sharp ## from former TS webpage To stay employed, you must be seen as a vital part of the company. This comes by your fulfilling several things at once: 1. Your skills are relevant to your manager's needs. 2. Your manager thinks you're a better alternative than anyone they could interview in the wild. 3. You're too important to lose. Many tech workers try to satisfy #3 at the expense of #2 by making it arbitrarily difficult to follow what they're doing, such as making overly complicated [algorithms](https://icould.fail/algorithms/) or maintaining an inferior platform or codebase instead of using something easier. However, the wiser way to keep yourself employed is to do what nobody else _wants_ to do. It's higher-risk and sometimes more unpleasant, but making your boss happy with your willingness to take on hard challenges will also make your boss afraid of losing you. Some of these unpleasant things will never be fashionable to tech workers: [Software automation](https://icould.fail/prog-habits/) is _amazing_, but it's not possible to entirely automate everything, and some things are destined to be difficult. - One of the more crucial components of working on a team is being able to handle [conflicts](https://adequate.life/conflicts/) with your peers and managers well, _not_ just being "really good" at something. Most people won't want to make the changes because they're often uphill. But, for the rest who take that road, it [builds character](https://gainedin.site/morality/) and makes life more [meaningful](https://gainedin.site/meaning/). Don't let yourself just be the best in the bunch. Be the person and do the things that people can't not talk about. ## tracking trends Carve out weekly time to investigate the bleeding edge. Research new technologies and to start to develop skills in them. Do hands-on work with these new technologies. Watch the alpha geeks. Rigid values make you fragile. The big problems I have successfully solved in my life. The secret is to focus on making whatever it is you're trying to improve better today than it was yesterday. That's it. It's easy. ## trying projects again Try a small project, twice. Try it once in your home base technology and then once, as idiomatically as possible, in a competing technology. ## atomization aka dynamic programming [Dynamic programming is not black magic | Hacker News](https://news.ycombinator.com/item?id=38988948) [Dynamic Programming is not Black Magic - Quentin Santos](https://qsantos.fr/2024/01/04/dynamic-programming-is-not-black-magic/) ## bad habits [Beau Lyddon](https://blog.realkinetic.com/stop-wasting-your-beer-money-12c3fe5e4d54?gi=f99e9ab30ea6) (2018) Stop Wasting Your Beer Money Why are engineers so bad at paying other engineers for their work? ## being productive [Lately I've been using timers daily | Hacker News](https://news.ycombinator.com/item?id=35972096) [blog/docs/timers.md at main · madprops/blog](https://github.com/madprops/blog/blob/main/docs/timers.md) [Want to be a better coder? Type faster.](https://htmlpasta.com/want-to-be-a-better-coder-type-faster/) [HTML Pasta](https://htmlpasta.com/) [Fuck being productive | Hacker News](https://news.ycombinator.com/item?id=35899518) [Fuck being productive. | 🐈 dostoynikov🐈 ](https://dostoynikov.bearblog.dev/fuck-being-productive/) [Unbundling Tools for Thought | Hacker News](https://news.ycombinator.com/item?id=34137751) [Unbundling Tools for Thought](https://borretti.me/article/unbundling-tools-for-thought) [Mise-en-place for knowledge workers | Hacker News](https://news.ycombinator.com/item?id=27708708) [Mise-en-Place for Knowledge Workers: 6 Practices for Working Clean - Forte Labs](https://fortelabs.com/blog/mise-en-place-for-knowledge-workers/) [Interview with a blind developer on how he works (2017) | Hacker News](https://news.ycombinator.com/item?id=39928679) [Software Development 450 Words Per Minute | Software Development](https://www.vincit.com/blog/software-development-450-words-per-minute) [Advice for new software devs who've read all those other advice essays | Hacker News](https://news.ycombinator.com/item?id=38706697) [Advice for new software devs who've read all those other advice essays • Buttondown](https://buttondown.email/hillelwayne/archive/advice-for-new-software-devs-whove-read-all-those/) [Java Code Geeks](https://www.javacodegeeks.com/2013/06/10-productivity-tips-for-software-developers.html) (2013) 10 Productivity tips for software developers [Itamar Turner-Trauring](https://codewithoutrules.com/productivity/) Become more productive ; articles about being more productive as programmer without necessarily working longer hours [Justyna Ilczuk](http://tinystruggles.com/2014/11/30/maker-productivity-101.html) (2014) Maker Productivity 101 [Ben Thompson](https://blog.gitprime.com/2017-software-developer-productivity-survey/) (2017) 2017 Software Developer Productivity Survey [Gaurav Makhecha](https://dev.to/gauravmak/time-saving-habits-for-programmers-i37) (2018) Time saving habits for programmers > - Forget office politics > - Code quality > - ... [Michael Malis](http://malisper.me/how-to-improve-your-productivity-as-a-working-programmer/) (2017) How to Improve Your Productivity as a Working Programmer It only takes one or two changes each week for things to quickly snowball. [How I Program in 2024 | Hacker News](https://news.ycombinator.com/item?id=41157494) [How I program in 2024](https://akkartik.name/post/programming-2024) [Primitive Recursive Functions for a Working Programmer | Hacker News](https://news.ycombinator.com/item?id=41146278) [Primitive Recursive Functions For A Working Programmer](https://matklad.github.io/2024/08/01/primitive-recursive-functions.html) ## being productive - automating tasks [/r/dailyscripts](https://www.reddit.com/r/dailyscripts/) late-night hacks lazy people made when too annoyed by a task's length or difficulty [Mattias Geniar](https://ma.ttias.be/why-do-we-automate/) Why do we automate? ## being productive - avoiding technical debt [Never update anything | Hacker News](https://news.ycombinator.com/item?id=29106159) [Never update anything | blog.kronis.dev](https://blog.kronis.dev/articles/never-update-anything) [No Config for Old Men | Hacker News](https://news.ycombinator.com/item?id=25238523) [No Config for Old Men | datagubbe.se](https://datagubbe.se/noconf/) ## being productive - clean code and software craftmanship [Goodbye, clean code (2020) | Hacker News](https://news.ycombinator.com/item?id=38566235) [Goodbye, Clean Code - overreacted](https://overreacted.io/goodbye-clean-code/) [Good code is like a love letter to the next developer who will maintain it | Hacker News](https://news.ycombinator.com/item?id=36807028) [Good code is like a love letter to the next developer who will maintain it. | Addy Osmani](https://addyosmani.com/blog/good-code/) [Smart Programmers Write STUPID Code (2022) | Hacker News](https://news.ycombinator.com/item?id=37777545) [Smart Programmers Write STUPID Code | by Brian Di Croce | Medium](https://bdicroce.medium.com/smart-programmers-write-stupid-code-397765a14b14) [Size is the best predictor of code quality (2011) | Hacker News](https://news.ycombinator.com/item?id=33566329) [Vivek Haldar - Size is the best predictor of code quality](https://blog.vivekhaldar.com/post/10669678292/size-is-the-best-predictor-of-code-quality) [Code is run more than read | Hacker News](https://news.ycombinator.com/item?id=38483181) [Code is run more than read | olano.dev](https://olano.dev/blog/code-is-run-more-than-read) [Write code. Not too much. Mostly functions. | Hacker News](https://news.ycombinator.com/item?id=25500671) [Write code. Not too much. Mostly functions. | Brandon's Website](https://www.brandons.me/blog/write-code-not-too-much-mostly-functions) [It's probably time to stop recommending Clean Code (2020) | Hacker News](https://news.ycombinator.com/item?id=27276706) [It's probably time to stop recommending Clean Code @ Things Of Interest](https://qntm.org/clean) [Donald Knuth was framed (2020) | Hacker News](https://news.ycombinator.com/item?id=31301777) [Donald Knuth was framed | Hacker News](https://news.ycombinator.com/item?id=22406070) [Donald Knuth Was Framed • Buttondown](https://buttondown.email/hillelwayne/archive/donald-knuth-was-framed/) [For Donald Knuth, good coding is synonymous with beautiful expression | Hacker News](https://news.ycombinator.com/item?id=22889195) [Quanta Magazine](https://www.quantamagazine.org/computer-scientist-donald-knuth-cant-stop-telling-stories-20200416/) [163: Donald Knuth - explain xkcd](https://www.explainxkcd.com/wiki/index.php/163:_Donald_Knuth) [coding style - Where did the notion of "one return only" come from? - Software Engineering Stack Exchange](https://softwareengineering.stackexchange.com/questions/118703/where-did-the-notion-of-one-return-only-come-from) [Clean Coder Blog](http://blog.cleancoder.com/) articles by Robert C. Martin (Uncle Bob) [Joshua Kerievsky](https://www.industriallogic.com/blog/whats-wrong-with-clean-code/) (2010) What’s Wrong With Clean Code? When Cleaning Is Not Enough > Clean frequently and remodel occasionally to produce an excellent design. [benas/awesome-software-craftsmanship](https://github.com/benas/awesome-software-craftsmanship) A curated list of awesome software craftsmanship resources [asciamanna/software-craftsmanship-catalog](https://github.com/asciamanna/software-craftsmanship-catalog/blob/master/catalog.md) a collection of resources about software craftsmanship, TDD, XP, etc. [Ronald Jeffries](https://www.ronjeffries.com/articles/017-08ff/clean-code/) (2017) Clean Code: A Learning [Jakub Holý](https://blog.jakubholy.net/craft/) Craft : About the craft of software development and why it matters. Archive of previous version about code quality only [Code (And Design) Quality And Why Should We Care.](https://web.archive.org/web/20170606194333/http://Theholyjava.wordpress.com/code-quality/) [Alvaro Videla](http://alvaro-videla.com/2014/09/a-programmers-role.html) (2014) A Programmer's Role, about what clean code was like in 1967 (1967) [PDF] Original publication [What Programmer Does](http://archive.computerhistory.org/resources/text/Knuth_Don_X4100/PDF_index/k-9-pdf/k-9-u2769-1-Baker-What-Programmer-Does.pdf) [Joël Spolsky](https://www.joelonsoftware.com/2003/12/01/craftsmanship-2/) (2003) Craftsmanship [Steve Barnegren](https://www.steveonstuff.com/2022/01/27/no-such-thing-as-clean-code) (2022) There’s No Such Thing as Clean Code [Ben Halpern](https://dev.to/ben/write-clean-code-and-avoid-the-distractions-of-emerging-technology-3emj) (2018) Write clean code and avoid the distractions of emerging technology stay excited by the trends, but be impassioned by the small improvements you can make in the quality of your work. [Jason McCreary](https://dev.to/gonedark/another-month-of-clean-code-4gig) (2017) Another month of clean code [Ravi Shankar Rajan](https://hackernoon.com/how-to-make-your-code-clean-and-beautiful-5ff7aee03be6) (2018) How to Make Your Code CLEAN and BEAUTIFUL [Jeff Atwood](https://blog.codinghorror.com/why-im-the-best-programmer-in-the-world/) (2004) Why I'm The Best Programmer In The World it's not our job to be better than anyone else; we just need to be better than we were a year ago. [Birat Rai](https://medium.com/@biratkirat/step-8-the-boy-scout-rule-robert-c-martin-uncle-bob-9ac839778385) (2017) Step 8: The Boy Scout Rule ~Robert C. Martin (Uncle Bob) > “Leave Things BETTER than you found them.” ~ Robert Baden Powell [Matt Butcher](http://technosophos.com/2018/07/04/be-nice-and-write-stable-code.html) (2018) Be Nice And Write Stable Code [Johannes Brodwall](http://johannesbrodwall.com/2018/06/24/forget-about-clean-code-lets-embrace-compassionate-code/) (2018) Forget about Clean Code, let’s embrace Compassionate Code Make people Awesome. Clean Code may help or hurt that goal. Learn to see the difference. [Jakub Holý](https://theholyjava.wordpress.com/2012/09/12/programming-like-kent-beck/) (2012) Programming Like Kent Beck [Michal Ciurus](http://yourcodesucksexception.blogspot.be/2015/08/the-clean-code-trap.html) (2015) The Clean Code Trap [Clean Code Cheat Sheet – planetgeek.ch](https://www.planetgeek.ch/2013/06/05/clean-code-cheat-sheet/?) ## being productive - delegating [Using load shedding to avoid overload | Hacker News](https://news.ycombinator.com/item?id=28818622) [Using load shedding to avoid overload](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/) [I just don't want to be busy anymore | Hacker News](https://news.ycombinator.com/item?id=28665065) [I Just Don't Want to Be Busy Anymore | by Elena Salaks | Forge](https://forge.medium.com/i-just-dont-want-to-be-busy-anymore-ac4dd37c8119) ## being productive - distractions [Programmers, teach non-geeks the true cost of interruptions (2014) | Hacker News](https://news.ycombinator.com/item?id=27787604) [Programmers, Teach Non-Geeks The True Cost of Interruptions - DaedTech](https://daedtech.com/programmers-teach-non-geeks-the-true-cost-of-interruptions/) [My seatbelt rule for judgment | Hacker News](https://news.ycombinator.com/item?id=30237457) [My Seatbelt Rule for Judgment](https://www.dannyguo.com/blog/my-seatbelt-rule-for-judgment/) [I'm a productive programmer with a memory of a fruit fly | Hacker News](https://news.ycombinator.com/item?id=32900164) [How I'm a Productive Programmer With a Memory of a Fruit Fly](https://hynek.me/articles/productive-fruit-fly-programmer/) [Chris Harris](https://medium.com/@otduet/yearly-lessons-learnt-by-a-freelance-developer-concerned-with-holistic-productivity-a84fdba685b) (2018) Yearly lessons learnt by a freelance developer concerned with holistic productivity. [Chris Parnin](https://github.com/chrisparnin/notes/blob/master/interruptions.md) (2014) Notes on Interruption for Programmers [Joël Spolsky](https://www.joelonsoftware.com/2001/02/12/human-task-switches-considered-harmful/) (2001) Human Task Switches Considered Harmful [Chris Parnin](http://blog.ninlabs.com/2013/01/programmer-interrupted/) (2013) Programmer Interrupted [Fadeke Adegbuyi](https://doist.com/blog/complete-guide-to-deep-work/) (2019) Deep Work: The Complete Guide (including a step-by-step checklist) ## being productive - do what works [Bad scientific code beats code following "best practices" (2014) | Hacker News](https://news.ycombinator.com/item?id=38872325) [Why bad scientific code beats code following "best practices"](https://yosefk.com/blog/why-bad-scientific-code-beats-code-following-best-practices.html) [Ask HN: What's your "it's not stupid if it works" story? | Hacker News](https://news.ycombinator.com/item?id=38733282) [Reject Simplicity, Embrace Complexity • Buttondown](https://buttondown.email/hillelwayne/archive/reject-simplicity-embrace-complexity) [Embrace Complexity; Tighten Your Feedback Loops](https://old.reddit.com/r/programming/comments/156cp10/embrace_complexity_tighten_your_feedback_loops/) ["Clean" code, horrible performance | Hacker News](https://news.ycombinator.com/item?id=34966137) ["Clean" Code, Horrible Performance - by Casey Muratori](https://www.computerenhance.com/p/clean-code-horrible-performance) ["What if it changes?" | Hacker News](https://news.ycombinator.com/item?id=31472997) [The mindless tyranny of 'what if it changes?' as a software design principle - Blogomatano](https://chriskiehl.com/article/the-tyranny-of-what-if-it-changes) [Do the simplest thing that can possibly work (2004) | Hacker News](https://news.ycombinator.com/item?id=34967685) [DTSTTCPW - What does it mean? - Software is too expensive to build cheaply….](https://twasink.net/2004/03/30/dtsttcpw-what-does-it-mean/) [You Don't Always Need to Follow Best Practices | Dev Tester](https://dev-tester.com/you-dont-always-need-to-follow-best-practices) [Joël Spolsky](https://www.joelonsoftware.com/2009/09/23/the-duct-tape-programmer/) (2009) The Duct Tape Programmer [Jeff Atwood](https://blog.codinghorror.com/we-make-shitty-software-with-bugs/) (2004) We Make Shitty Software.. With Bugs! Software is a process, it's never finished, it's always evolving. [Brandon Sheffield](https://www.gamasutra.com/view/news/310570/Developers_share_their_most_memorable_dirty_coding_tricks.php) (2017) Developers share their most memorable dirty coding tricks [Dan Kim](https://m.signalvnoise.com/its-ok-to-be-pragmatic-with-a-little-help-from-the-crazy-ones-461f7773a176) It’s OK to be pragmatic (with a little help from the “crazy ones”) [John D. Cook](https://www.johndcook.com/blog/2009/12/16/good-work-with-bad-tools/) (2009) Doing good work with bad tools [Worse is better](https://en.wikipedia.org/wiki/Worse_is_better) It is the subjective idea that quality does not necessarily increase with functionality—that there is a point where less functionality ("worse") is a preferable option ("better") in terms of practicality and usability. Software that is limited, but simple to use, may be more appealing to the user and market than the reverse. [Deon Thomas](https://www.thoughtworks.com/insights/blog/good-programer-avoid-being-one) (2014) A Good Programmer: Why You Need to Avoid Being One [Laura Klein](https://www.usersknow.com/blog/2016/5/23/good-enough) (2016) Good Enough You don't know what "perfect" means. [Hugo Sharman-Firth](https://blog.hugo.codes/2018/08/the-dangers-of-best-practices.html) (2018) The dangers of best practices Best is the enemy of better [Itamar Turner-Trauring](https://codewithoutrules.com/2017/01/19/specialist-vs-generalist/) (2017) Why you should have the skills of a generalist, but market yourself as a specialist ## being productive - failing fast [Lieven Vaneeckhaute (denshade)](https://softwareefficiency.wordpress.com/2015/02/10/fail-fast-spend-less-time-in-root-cause-analysis/) (2015) Fail fast, spend less time in root cause analysis [Vadim Kravcenko](http://vadimkravcenko.com/dealing-with-complex-projects) (2018) Dealing with complex projects > If you fail - you learn, if you succeed – even better. And never forget the importance of communication. ## being productive - fnding creative solutions [Engin Yöyen](http://enginyoyen.com/improving-problem-solving-skills-for-developers/) Improving problem-solving skills for developers ## being productive - focus on quality [Gregg Caines](http://caines.ca/blog/2010/12/05/quality-is-the-constraint/) (2010) Quality Is the Constraint [Meghan Hebel](https://codeburst.io/stop-sabotaging-your-code-4ed67424a17a) Stop Sabotaging Your Code…Before You Even Code [Unix Sheikh](https://www.unixsheikh.com/articles/how-to-write-software-than-will-keep-working-for-decades.html) (2021) How to write software than will keep working for decades without problems [Steve McConnell](http://stevemcconnell.com/articles/real-quality-for-real-engineers/) (2012) Real Quality For Real Engineers [Steve McConnell](http://stevemcconnell.com/articles/software-quality-at-top-speed/) (1996) Software Quality at Top Speed [Martin Fowler](https://martinfowler.com/articles/is-quality-worth-cost.html) (2019) Is High Quality Software Worth the Cost? [David John Adams aka DJ Adams](https://qmacro.org/2021/02/01/do-less-and-do-it-better/) (2021) Do less and do it better [Seth Godin](https://seths.blog/2018/11/quality-and-effort/) (2018) Quality and effort > * We need to put care into our systems. We need to build checklists and peer review and resilience into the way we express our carefulness. > * It seems ridiculous that a surgeon needs to write her name (with a Sharpie) on the limb that she’s about to operate on, but this simple system adjustment means that errors involving working on the wrong limb will go to zero. > * Instead of reacting to an error with, “I need to be more careful,” we can respond with, “I can build a better system.” > * If it matters enough to be careful, it matters enough to build a system around it. [Martin Fowler's tweet](https://twitter.com/martinfowler/status/1057971818768818177) "Don't teach people to be careful, instead get them to build systems that resist faults" [Zach Holman](https://zachholman.com/talk/move-fast-break-nothing/#slides) move fast & break nothing a talk about code, teams & process [Steven A. Lowe](https://techbeacon.com/program-faster-all-time-best-tips-pros) Code faster: 53 tips from the pros > The only way to go fast is to go well. Every time you yield to the temptation to trade quality for speed, you slow down. Every time. [Robert C. Martin](http://butunclebob.com/ArticleS.UncleBob.VehementMediocrity) [Petter Måhlén](https://labs.spotify.com/2014/04/11/qualities-of-quality/) (2014) Qualities of Quality Spotify Labs [Yunkai Zhou](https://medium.freecodecamp.org/climbing-the-code-quality-ladder-babd3198e6e2) (2018) Climbing The Code Quality Ladder [The Twelve-Factor App (2011) | Hacker News](https://news.ycombinator.com/item?id=37857544) [The Twelve-Factor App](https://12factor.net/) is a methodology for building software-as-a-service apps of great quality [Rich Archbold](https://www.intercom.com/blog/run-less-software/) (2018) Run less software 1. Choose standard technology 2. Outsource Undifferentiated Heavy Lifting 3. Create enduring competitive advantage [Gregg Caines](http://caines.ca/blog/2018/03/27/zero-defect-policy/) (2018) Zero Defect Policy [Ashton Kemerling](https://web.archive.org/web/20170711011635/http://ashtonkemerling.com/blog/2014/03/24/disdain/) (2014) Disdain the accomplished engineer knows that completing a task is not about the number of hours spent, but the quality [Heinrich Hartmann](https://www.heinrichhartmann.com/archive/quality-time.html) (2018) Quality Time ## being productive - grinding [What I Worked On | Hacker News](https://news.ycombinator.com/item?id=26155350) [What I Worked On](https://paulgraham.com/worked.html) [Six Months of Tiny Projects | Hacker News](https://news.ycombinator.com/item?id=25135752) [Six months of Tiny Projects | Tiny Projects](https://tinyprojects.dev/posts/six_months_of_tiny_projects) [Grind Smarter, not Harder • Buttondown](https://buttondown.email/hillelwayne/archive/grind-smarter-not-harder) [Work Hard (2007) | Hacker News](https://news.ycombinator.com/item?id=28318972) [Work hard | What's new](https://terrytao.wordpress.com/career-advice/work-hard/) [Evil programmer's tip: avoid "easy" things (2016) | Hacker News](https://news.ycombinator.com/item?id=27988260) [Evil tip: avoid "easy" things](https://yosefk.com/blog/evil-tip-avoid-easy-things.html) [Consume less, create more | Hacker News](https://news.ycombinator.com/item?id=20781463) [Consume less, create more - TJCX](https://blog.tjcx.me/p/consume-less-create-more) [Move Slow and Make Things | Hacker News](https://news.ycombinator.com/item?id=26668806) [Move Slow and Make Things | Stitch Fix Technology - Multithreaded](https://multithreaded.stitchfix.com/blog/2021/04/01/move-slow-make-things/) [Some reasons to work on productivity and velocity | Hacker News](https://news.ycombinator.com/item?id=28882043) [Some reasons to work on productivity and velocity](https://danluu.com/productivity-velocity/) [Embrace the Grind | Hacker News](https://news.ycombinator.com/item?id=26747305) [Embrace the Grind - Jacob Kaplan-Moss](https://jacobian.org/2021/apr/7/embrace-the-grind/) [Programming is hard | Hacker News](https://news.ycombinator.com/item?id=26711862) [Programming is hard - dorinlazar.ro](https://dorinlazar.ro/2021-02-programming-is-hard/) [The Grug Brained Developer | Hacker News](https://news.ycombinator.com/item?id=31840331) [The Grug Brained Developer (2022) | Hacker News](https://news.ycombinator.com/item?id=38076886) [The Grug Brained Developer](https://grugbrain.dev/) [Screw motivation, what you need is discipline | Hacker News](https://news.ycombinator.com/item?id=34692137) [Screw motivation, what you need is discipline. - WISDOMINATION](https://www.wisdomination.com/screw-motivation-what-you-need-is-discipline/) [Software Disenchantment (2018) | Hacker News](https://news.ycombinator.com/item?id=21929709) [Software disenchantment | Hacker News](https://news.ycombinator.com/item?id=37985176) [Software disenchantment @ tonsky.me](https://tonsky.me/blog/disenchantment/) [John D. Cook](https://www.johndcook.com/blog/2009/03/18/where-does-the-programming-effort-go/) (2009) Where does the programming effort go? [Andre Meyer](http://www.felienne.com/archives/3665) (2014) Software developer’s perceptions of productivity [Emily Yu](https://hackernoon.com/how-i-coded-everyday-for-365-days-67ebb5fc7ae) (2018) How I Coded Everyday for 365 Days [Lou Bichard](https://simpleprogrammer.com/overcoming-obstacles-stoic-mindset/) (2018) Overcoming Programmer Career Obstacles With A Stoic Mindset [Jessica Joy Kerr aka jessitron](https://jessitron.com/2017/06/24/the-most-productive-circumstances-for/) (2017) Hyperproductive development [John Cutler](https://hackernoon.com/faster-faster-faster-231c7b3d088d) (2017) Faster. Faster. Faster. [Thomas Peham](https://usersnap.com/blog/faster-programming/) (2016) How to be a faster programmer: 7 helpful tips for being faster & more successful. [Max Kanat-Alexander](https://www.codesimplicity.com/post/the-secret-of-fast-programming-stop-thinking/) (2013) The Secret of Fast Programming: Stop Thinking [Mike Cannon-Brookes](https://medium.com/smells-like-team-spirit/an-amateurs-guide-to-turning-impostor-syndrome-into-an-asset-1bac56917d46) An amateur’s guide to turning impostor syndrome into an asset [Lin Taylor](http://linbug.github.io/self-improvement/personal%20tracking/imposter%20syndrome/2017/09/30/How-I-hacked-my-imposter-syndrome-using-personal-tracking/) (2017) How I hacked my imposter syndrome using personal tracking [Seth Godin](https://seths.blog/2005/03/dont_shave_that/) (2005) Don’t Shave That Yak! > * The minute you start walking down a path toward a yak shaving party, it’s worth making a compromise. Doing it well now is much better than doing it perfectly later. ## being productive - hitting a wall [I'm taking some time away from Comma | Hacker News](https://news.ycombinator.com/item?id=33406790) [The Hero's Journey | the singularity is nearer](https://geohot.github.io//blog/jekyll/update/2022/10/29/the-heroes-journey.html) [I don't like making the best things | Hacker News](https://news.ycombinator.com/item?id=34816145) [I don't like making the best things](https://internetvin.ghost.io/i-dont-like-making-the-best-things/) [Making Hard Things Easy | Hacker News](https://news.ycombinator.com/item?id=37791002) [New talk: Making Hard Things Easy](https://jvns.ca/blog/2023/10/06/new-talk--making-hard-things-easy/) [The hardest part of building software is not coding, it's requirements : programming](https://old.reddit.com/r/programming/comments/16t2pk8/the_hardest_part_of_building_software_is_not/) [My $500M Mars rover mistake | Hacker News](https://news.ycombinator.com/item?id=38452959) [My $500M Mars Rover Mistake: A Failure Story - Chris Lewicki](https://www.chrislewicki.com/articles/failurestory) [Why I'm a sucker for pen and paper | Hacker News](https://news.ycombinator.com/item?id=26596316) [Why I'm a sucker for pen and paper - by Andrea](https://productivegrowth.substack.com/p/why-im-a-sucker-for-pen-and-paper) [Ask HN: How to improve as a struggling junior software engineer? | Hacker News](https://news.ycombinator.com/item?id=30974544) [DataFire](https://datafire-repos.github.io/oblique-strategies/) Oblique Strategies for Programmers : Random tips for building, debugging, and overcoming creative blocks. [Jérôme Beau](https://javarome.medium.com/developers-bad-habits-2e99a174b514) (2021) Developers Bad habits You don’t want to do that [Itamar Turner-Trauring](https://codewithoutrules.com/2016/12/08/how-not-to-get-stuck/) (2016) Don’t get stuck: 6 ways to get unstuck and code faster [Itamar Turner-Trauring](https://codewithoutrules.com/2016/02/24/go-home-already/) (2016) Still stuck at the end of the day? [Michael Hoffman](http://code-worrier.com/how-to-be-stuck/#) (2013) How to be Stuck - Learning to learn to code on the internet ## being productive - libraries vs frameworks or services [Write Libraries, Not Frameworks | Hacker News](https://news.ycombinator.com/item?id=23121192) [Write Libraries, Not Frameworks | Brandon's Website](https://www.brandons.me/blog/libraries-not-frameworks) [Write libraries instead of services, where possible | Hacker News](https://news.ycombinator.com/item?id=26398960) [Write libraries instead of services, where possible](https://catern.com/services.html) ## being productive - making decisions [Engineers should invest in decision-making skills early | Hacker News](https://news.ycombinator.com/item?id=29720000) [Strategic Decision Making Skills For Engineers - Reforge](https://www.reforge.com/blog/technical-decision-making) ## being productive - metrics [6 days to change 1 line of code (2015) | Hacker News](https://news.ycombinator.com/item?id=36746014) [It Takes 6 Days to Change 1 Line of Code - ed weissman](https://edw519.posthaven.com/it-takes-6-days-to-change-1-line-of-code) ["This project will only take 2 hours" | Hacker News](https://news.ycombinator.com/item?id=29161194) ["This project will only take 2 hours" - Austin Z. Henley](https://web.archive.org/web/20211108192716/https://web.eecs.utk.edu/~azh/blog/thisprojectwillonlytake.html) [Always Multiply Your Estimates by π (2013) | Hacker News](https://news.ycombinator.com/item?id=28667174) [Always Multiply Your Estimates by π - 推酷](https://web.archive.org/web/20170603123809/http://www.tuicool.com:80/articles/7niyym) [Past Performance is Not Indicative of Future Results (2020) | Hacker News](https://news.ycombinator.com/item?id=28019094) [Cory Doctorow: Past Performance is Not Indicative of Future Results - Locus Online](https://locusmag.com/2020/11/cory-doctorow-past-performance-is-not-indicative-of-future-results/) [Tyler Hakes](https://www.7pace.com/blog/how-to-measure-developer-productivity) (2018) How to Measure Developer Productivity > It’s easy to accomplish 100 small tasks to make yourself look more productive. But in many cases, it’s the one, big, ugly project that takes the most time and is holding us (and the rest of the team) back from moving forward. > Measuring productivity can be difficult. But using the wrong metrics makes it impossible. [Lieven Vaneeckhaute (denshade)](https://softwareefficiency.wordpress.com/2015/09/20/measuring-programmer-competency/) (2015) Measuring programmer competency ## being productive - mostly useless work [Most data work seems fundamentally worthless | Hacker News](https://news.ycombinator.com/item?id=34955309) [Most Data Work Seems Fundamentally Worthless - Ludicity](https://ludic.mataroa.blog/blog/most-data-work-seems-fundamentally-worthless/) [Let a thousand flowers bloom, then rip 999 of them out | Hacker News](https://news.ycombinator.com/item?id=10294833) [Let a 1,000 flowers bloom. Then rip 999 of them out by the roots.](https://gigamonkeys.com/flowers/) [Write more "useless" software | Hacker News](https://news.ycombinator.com/item?id=37911900) [Write more "useless" software | nicole@web](https://ntietz.com/blog/write-more-useless-software/) [You don't need a build step | Hacker News](https://news.ycombinator.com/item?id=34996727) [You Don't Need a Build Step](https://deno.com/blog/you-dont-need-a-build-step) ## being productive - optimizing workspace [Ideal monitor rotation for programmers (2021) | Hacker News](https://news.ycombinator.com/item?id=38802086) [Ideal monitor rotation for programmers](https://sprocketfox.io/xssfox/2021/12/02/xrandr/) [New Essay, some thoughts on method vs process • Buttondown](https://buttondown.email/hillelwayne/archive/new-essay-some-thoughts-on-method-vs-process) ## being productive - organizing [Ask HN: How do you share/organize knowledge at work and life? | Hacker News](https://news.ycombinator.com/item?id=21310030) [Hacking ADHD: Strategies for the modern developer | Hacker News](https://news.ycombinator.com/item?id=38274782) [Hacking ADHD - Strategies for the Modern Developer | Ledger](https://www.ledger.com/blog/hacking-adhd-strategies-for-the-modern-developer) ## being productive - paying attention [Attention Is My Most Valuable Asset for Productivity as a Software Developer | Hacker News](https://news.ycombinator.com/item?id=25030938) [Attention Is My Most Valuable Asset for Productivity as a Software Developer | zwbetz](https://zwbetz.com/attention-is-my-most-valuable-asset-for-productivity-as-a-software-developer/) [The most precious resource is agency | Hacker News](https://news.ycombinator.com/item?id=27695181) [The Most Precious Resource is Agency - by Simon Sarris](https://map.simonsarris.com/p/the-most-precious-resource-is-agency) [Never trust a system that seems to be working | Hacker News](https://news.ycombinator.com/item?id=33233720) [foone🏳️ ⚧️ on Twitter: "so a fun thing about f*ctorio's space exploration mod is that you can screw up and inadvertently recreate a pivotal moment from Robert Heinlein's The Moon Is A Harsh Mistress: the bombing of earth using the lunar grain deliveries!" / Twitter](https://web.archive.org/web/20221016135400/https://twitter.com/Foone/status/1581643197427523584) [The most copied StackOverflow snippet of all time is flawed (2019) | Hacker News](https://news.ycombinator.com/item?id=37674139) [The most copied StackOverflow snippet of all time is flawed (2019) | Hacker News](https://news.ycombinator.com/item?id=27533684) [The most copied StackOverflow snippet of all time is flawed! | Programming.Guide](https://programming.guide/worlds-most-copied-so-snippet.html) ## being productive - shipping creates confidence [For your next side project, make a browser extension | Hacker News](https://news.ycombinator.com/item?id=34391619) [For your next side project, make a browser extension](https://www.geoffreylitt.com/2023/01/08/for-your-next-side-project-make-a-browser-extension.html) [Ken Thompson's keynote talk about a jukebox he built [video] | Hacker News](https://news.ycombinator.com/item?id=35218463) [Ken Thompson - Closing Keynote - SCaLE 20x - YouTube](https://www.youtube.com/watch?v=kaandEt_pKw) ## being productive - slow programming [Jeffrey Ventrella](https://ventrellathing.wordpress.com/2013/06/18/the-case-for-slow-programming/) (2013) The Case for Slow Programming “Slow down, son. You’ll get the job done faster.” [Esther Schindler](https://blog.newrelic.com/2016/02/22/8-ways-become-a-better-coder/) (2016) 8 Ways to Become a Better Coder > “The code works” isn’t where you stop; it’s where you start [Umer Mansoor](https://codeahoy.com/2016/06/03/write-less-code/) (2016) Write Less Code [Shaun Finglas](https://blog.shaunfinglas.co.uk/2015/09/waste-write-less-code.html) (2015) Waste: Write Less Code [Alicia Liu](https://medium.com/counter-intuition/go-slow-to-go-fast-part-1-you-a4974ceb8a7c) (2018) Go Slow to Go Fast [Part 1: You](https://medium.com/counter-intuition/go-slow-to-go-fast-part-1-you-a4974ceb8a7c) [Part 2: Team](https://medium.com/counter-intuition/go-slow-to-go-fast-part-2-team-e793bb0d658a) [Part 3: World](https://medium.com/counter-intuition/go-slow-to-go-fast-part-3-world-efb76c4de220) [Jonas Downey](https://m.signalvnoise.com/move-slowly-and-fix-things-e5a560fd928b) (2017) Move Slowly and Fix Things Ruminations on the heavy weight of software design [Logan Mayville](https://www.hellosign.com/blog/busy-kills-productivity) (2018) How Being Busy Kills Productivity How doing less can help you be more productive > * Focus on results; not time : Time tracking is unavoidable in some instances, but rather than the rule by which companies operate, it should be used as a secondary metric to the results they achieve. Rather than give an employee a 2-hour window to do a job, have her do it right the first time (bonus points for documenting the process), then review and adjust your future plans based on time tracking data. > * Improve systems : Improving systems helps remove busywork from an employee’s day, but it also makes things easier for the customer. > * Whether you’re getting a lot of satisfaction from being busy or just feeling exasperated, don’t forget to occasionally stop and ask yourself: Is this the best use of time? How doing less can help you be more productive > * Focus on a single strategy > * Focus on results; not time > * Improve systems [Calm Tech](https://calmtech.com/) Principles of Calm Technology [Tanmay Vora](http://qaspire.com/2012/09/21/a-gentle-friday-reminder-go-slow/) (2012) A Gentle Friday Reminder: Go Slow > * You are moving too fast. Overwhelmed with everything, good or bad, happening around. > * Life is too short (really) to zoom past it. > * People who survive (and grow) are the ones who stay in the moment, concentrate and strive to deliver their best. > * Quality never comes from rushing through things. > * Just because you can do so many things doesn’t mean you should attempt all of them. > * Rushing too fast through these is a risk, it is a killer. You never savor the moment, be in the present and enjoy the process. You end up ‘doing’ so much that there is no time to ‘ruminate’ [Slow Programming](https://slowprogramming.com/) Programming has become a pursuit of profit over personal knowledge. The craft of programming has developed into a rapid rush to the finish line via bootcamps and brief tutorials. [Nikol](https://pro-wp.in.ua/stop-a-moment-slow-programming-is-a-trend-for-tired-developers/) (2023) Stop a moment. Slow programming is a trend for tired developers [George Gritsouk](https://gggritso.com/legacy-code) (2016) Legacy Code The noblest pursuit of our weekdays slow programming [Itamar Turner-Trauring](https://codewithoutrules.com/2016/06/26/code-faster/) (2016) Code faster by typing less ### Slow programming principles * No broken window. A repo should always be in a clean and working state, i.e the last commit should always build successfully. * If you broke it, take ownership for the repair. If you break something, you are responsible of the situation, fix it (it's ok to ask for help). * Avoid branching/batching your changes | Be careful what you batch. Changes and version bumps should be integrated continuously, not all at once. * Don't hide your work, branch instead, and get it reviewed before creating a PR / merging it. * If possible, don't branch, work on trunk/main. Branching/Feature flags can help. * Use Peer code review, if possible pre-commit reviews. Peer code review is a key element in building a robust and egoless engineering culture of collaborative problem-solving ([source](https://semaphoreci.com/blog/cicd-pipeline)) * If you change the principles/systems/processess, do it incrementally. Developer productivity matters a lot. Minimize friction. e.g don't do a migration of all CI/CD Ecosystem in a way that breaks everything for a while. Do it step by step, phase the changes. Make it possible to rollback easily to previous working state. * Quality first | Quality is always right. If you’re doing CI and for some reason the integration fails, that means the broken build becomes the highest priority to fix before continuing to add more features. System quality—not just velocity—is important. CI works in three simple stages: push, test, and fix. But despite this simplicity, CI might become challenging if only a few members of the team practice it. Consequently, CI also requires a change in culture and support from management. [source](https://stackify.com/what-is-cicd-whats-important-and-how-to-get-it-right/) * There is never enough time to do it right yet we find time to do it again and again. Jack Bergman? * Refactoring can only truly begin once you've actually learned what a piece of code or some data structure did, the unique properties for which they were written or chosen. Anything else is setting yourself up for failure. [source](https://ferd.ca/lessons-learned-while-working-on-large-scale-server-software.html) * It also means that when building systems, you should not assume that operators will do things correctly. Expect failure from people. Try to think about tools you can give them to undo their mistakes, because they will happen sooner or later. Have some dread. Be understanding. Know things won't be perfect. [source](https://ferd.ca/lessons-learned-while-working-on-large-scale-server-software.html) * Study your tools, see how you work, understand how you can improve it. Don't rush. Before you run, you have to learn to walk. * Whether you’re getting a lot of satisfaction from being busy or just feeling exasperated, don’t forget to occasionally stop and ask yourself: Is this the best use of time? * Improve systems : Improving systems helps remove busywork from an employee’s day, but it also makes things easier for the customer. * See also: [Ref : How Being Busy Kills Productivity](https://www.hellosign.com/blog/busy-kills-productivity) on how doing less can help you be more productive * Focus on results; not time : Time tracking is unavoidable in some instances, but rather than the rule by which companies operate, it should be used as a secondary metric to the results they achieve. Rather than give an employee a 2-hour window to do a job, have her do it right the first time (bonus points for documenting the process), then review and adjust your future plans based on time tracking data. * Do one thing at a time. Only one item under your name in the WIP. The rest will wait. You cannot fix all things. * Test the crap out of everything you do before telling anyone you are "finished". See also [Ref : Being a slow programmer](https://shansvex.wordpress.com/2013/12/03/being-a-slow-programmer/) * Use right tools for the job (email != todo list, PR and commits != code documentation, Jenkins != long term storage for releases/versions/build info/state of quality of your code) * Love what you have. Using boring technology. Don't get distracted too often with shiny tools that reinvent the wheel. * Write less code, read more than you write. Read more tips, manuals, blogs, articles, watch presentations and listen to podcasts about your programming craft. Learn from others prior to writing bugs. As with culture and and knowledge, you are the books you read, the films you watch, the music you listen to, the people you spend time with, the conversations you engage in. Choose wisely what you feed your mind with, and it's true with code as well. See also [Ref : Being a slow programmer](https://shansvex.wordpress.com/2013/12/03/being-a-slow-programmer/) and [Ref : Learn to Read the Source, Luke](https://blog.codinghorror.com/learn-to-read-the-source-luke/) * Learn how to write clean code, and repeat. So when you will have to rush, you will not forget to do your work right, and you will naturally provide more quality work. Also you will tend to detect issues earlier before they hit production, i.e during reviews, and writing better code will lead the whole team in getting a better codebase you can all be proud of, which mean work will become more agreeable. * Do your research, don't always rush in coding or in reinventing the wheel. You will learn a lot through research. * Don't react yet. Take a little time before taking action / reacting to a task/request/message. It allows you to think more about your answer / action. Also, ask yourself if you really need to take action now for this task, or if it can wait later in the day/week. Check if you're not giving the task more focus/consideration than it deserves. * Wait before jumping immediately on every opportunity/request/problem. Don’t touch it / don’t (re)act too soon * :star: Respond rather than react * Before you write any code, think first about what problem this is solving and for whom. See also: [Ref : Think first about what problem this is solving and for whom](https://letterstoanewdeveloper.com/2021/01/18/think-first-about-what-problem-this-is-solving-and-for-whom/) * The faster you react, the less you think. Not always, but often. [Ref : Give it five minutes](https://signalvnoise.com/posts/3124-give-it-five-minutes) * See also: [Ref : How Being Busy Kills Productivity](https://www.hellosign.com/blog/busy-kills-productivity) on how doing less can help you be more productive * Reuse existing code. GitHub is your friend. * Discipline / Consistency beat motivation and quality. * You don't want heroes, but you might benefit from experts / excellents colleagues / colleagues & managers that provide support and insights and who do not let you take everyting on your plate. * Simplify. Become a minimalist. * Don't be overconfident | the fallacy of skipping the planning stage. Some tasks look simple at first glance, but it can hide some challenges. Take the time needed to run your analysis and estimate the effort after you have checked all possible impacts you could check. Overestimating is one thing, but underestimating the effort and challenge can really lead to getting cascade issues and mistakes that would add a lot of pressure on every team and lead then to rushing even more and causing even bigger mistakes. See also [Ref : Skipping the planning stage](https://www.caines.ca/blog/2009/12/13/code-slower/) * Writing classes and functions that do a lot. * Be helpful not harmful, fix things and care more about your impact. You have a big responsibility on your hands, and you should take it seriously. The world needs as much care and conscience as we can muster. Defend your users against anti-patterns and shady business practices. Raise your hand and object to harmful design ideas. Call out bad stuff when you see it. Thoughtfully reflect on what you’re sending out into the world every day. See also: [Ref : Move Slowly and Fix Things](https://m.signalvnoise.com/move-slowly-and-fix-things/) * Comment. * More so than all other tools (issue tracker, code management system, etc.) comments in code have the greatest chance of still being around and easily searchable if they haven't been deleted. See also: [Ref : The case for comments in code](https://notes.eatonphil.com/the-case-for-comments-in-code.html) * Code can’t self-document if it isn’t there. If you decide to not write some code and don’t leave a comment explaining why, there will be nothing left to explain what you were thinking! Add comments that explain why the code is doing what it is doing, or is structured the way that it is structured. See also: [Ref : How to write readable code](https://jeremymikkola.com/posts/2021_02_02_how_to_write_readable_code.html) * When you're done with your commit and push, just double check what you have just done. Sometimes issues or possible improvements appear obvious only when the work is already pushed. Next time, slow down and double check before pushing ;-) * Make your app fail fast in case of error. Ignoring errors will have side effects and can cause even more harm than if you just had the app crashing on first error. * Focus on simplicity. The answer is always there. [source](https://blog.strategicedge.co.uk/2013/03/tidy-up-as-you-go-along-be-it-cooking-diy-or-selling-your-software-solution-remember-the-small-stuff-as-it-is-big-stuf.html) * Slow is steady. Steady is smooth. Smooth is fast. [Source](https://twitter.com/DanielMiessler/status/1406038903878868992) ### Slow programming Healthy tips / helpers * Disconnect & Focus. Value your time, use it to focus. Put lot of non-meeting blocks in your agenda. * Stay positive. Focus on what is doing ok, what you have accomplished. Focus your brain attention more often on something that is stress free. * Limit your coffee intake. * Drinking caffeine triggers the release of adrenaline. Adrenaline is the source of the “fight-or-flight” response, a survival mechanism that forces you to stand up and fight or run for the hills when faced with a threat. The fight-or-flight mechanism sidesteps rational thinking in favor of a faster response. This is great when a bear is chasing you, but not so great when you’re responding to a curt email. [source](https://www.linkedin.com/pulse/20140805002649-50578967-how-successful-people-stay-calm/) * Less caffeine. More hot water and sliced ginger. [source](https://blog.strategicedge.co.uk/2013/03/tidy-up-as-you-go-along-be-it-cooking-diy-or-selling-your-software-solution-remember-the-small-stuff-as-it-is-big-stuf.html) * Get enough sleep. * When you sleep, your brain literally recharges, shuffling through the day’s memories and storing or discarding them (which causes dreams), so that you wake up alert and clear-headed. Your self-control, attention, and memory are all reduced when you don’t get enough—or the right kind—of sleep. Sleep deprivation raises stress hormone levels on its own, even without a stressor present. Stressful projects often make you feel as if you have no time to sleep, but taking the time to get a decent night’s sleep is often the one thing keeping you from getting things under control. [source](https://www.linkedin.com/pulse/20140805002649-50578967-how-successful-people-stay-calm/) * The alarm clock is for back-up. Not wake up: get enough sleep. [source](https://blog.strategicedge.co.uk/2013/03/tidy-up-as-you-go-along-be-it-cooking-diy-or-selling-your-software-solution-remember-the-small-stuff-as-it-is-big-stuf.html) * Look for help | Use your support system. It’s tempting, yet entirely ineffective, to attempt tackling everything by yourself. To be calm and productive, you need to recognize your weaknesses and ask for help when you need it. This means tapping into your support system when a situation is challenging enough for you to feel overwhelmed. Everyone has someone at work and/or outside work who is on their team, rooting for them, and ready to help them get the best from a difficult situation. Identify these individuals in your life and make an effort to seek their insight and assistance when you need it. Something as simple as talking about your worries will provide an outlet for your anxiety and stress and supply you with a new perspective on the situation. Most of the time, other people can see a solution that you can’t because they are not as emotionally invested in the situation. Asking for help will mitigate your stress and strengthen your relationships with those you rely upon. [source](https://www.linkedin.com/pulse/20140805002649-50578967-how-successful-people-stay-calm/) * Breathe. The practice of being in the moment with your breathing will begin to train your brain to focus solely on the task at hand and get the stress monkey off your back. When you’re feeling stressed, take a couple of minutes to focus on your breathing. Close the door, put away all other distractions, and just sit in a chair and breathe. The goal is to spend the entire time focused only on your breathing, which will prevent your mind from wandering. Think about how it feels to breathe in and out. This sounds simple, but it’s hard to do for more than a minute or two. It’s all right if you get sidetracked by another thought; this is sure to happen at the beginning, and you just need to bring your focus back to your breathing. If staying focused on your breathing proves to be a real struggle, try counting each breath in and out until you get to 20, and then start again from 1. Don’t worry if you lose count; you can always just start over. [source](https://www.linkedin.com/pulse/20140805002649-50578967-how-successful-people-stay-calm/) * Drink / eat well. * Don’t forget to drink water, get sunlight, and that we are basically a house plant with complicated feelings. [source](https://twitter.com/TheWeirdWorld/status/930155807651528706) * Often when we think we are hungry we are simply thirsty. Drink water first. [source](https://blog.strategicedge.co.uk/2013/03/tidy-up-as-you-go-along-be-it-cooking-diy-or-selling-your-software-solution-remember-the-small-stuff-as-it-is-big-stuf.html) * Drink decent tea and coffee. Do the simple pleasures properly. [source](https://blog.strategicedge.co.uk/2013/03/tidy-up-as-you-go-along-be-it-cooking-diy-or-selling-your-software-solution-remember-the-small-stuff-as-it-is-big-stuf.html) * Eat slowly * Let things blow up from time to time, you're not your work, don't feel you are not responsible for everything within your employer's company, and your employer is more resilient than you think. * Check your posture. It will reflect how you are treating your body. [source](https://blog.strategicedge.co.uk/2013/03/tidy-up-as-you-go-along-be-it-cooking-diy-or-selling-your-software-solution-remember-the-small-stuff-as-it-is-big-stuf.html) * [Unix Sheikh](https://www.unixsheikh.com/about.html) software engineering principles > * Simplicity: The system should always be as simple and small as possible. When software projects grow, so do errors and bugs. Techniques such as line-by-line inspection of software, relevant unit testing, and physical examination of hardware that implements protection mechanisms are great. For such techniques to be successful a small and simple design is essential. This is sometimes described as the KISS principle and YAGNI. > * Least privilege: Each user and program should operate using the fewest privileges possible. > * Open design: In order for a system to be secure it must never depend on attacker ignorance. Instead the design should be based upon technology that depend upon public scrutiny - whenever possible. > * Complete mediation: Every access attempt must be checked and validated. > * Easy to use: The human interface must be as easy and intuitive to use as possible. Easy and simple is always better than smart and fancy. Simple user testing is a great way to get valuable feedback. > * Usability: Well known usability standards should be met if required. > * Discrimination: User discrimination is never good. User discrimination is when an application only works for a very limited amount of systems, like when a website only works with JavaScript enabled even though it doesn't provide any functionality that really requires JavaScript. > * Documentation: Lacking or inadequate documentation is a bug. Everything needs to be adequately documented from the very beginning, it is an integrate part of software development. I strongly abhor poor or lacking documentation. [Jeremy Mikkola](https://jeremymikkola.com/posts/2021_02_02_how_to_write_readable_code.html) (2021) How to write readable code > * Prioritize Clarity : The first step to writing clear code is to make it a priority. > * Develop a sense for clarity : requires knowing what clear code looks like. > * Edit : Reading back over what you just wrote will help give ideas for how to improve it. > * Start by explaining : start by explaining what needs to be done as though you are telling it to another person (or rubber duck). Write it down. Take that explanation and transform it into code. > * Comments : Code can’t self-document if it isn’t there. If you decide to not write some code and don’t leave a comment explaining why, there will be nothing left to explain what you were thinking! > * Don’t mix levels : Mixing levels of abstraction makes the reader jump between thinking about what is being done and how it is implemented. > * Break out functions - :duck: self-comment here : It's true to some extent, but breaking a code in too many functions can also force jumping a lot between code locations. So I would say it depends on the semantic and scope distance between those functions. > * Don’t break out functions : DRY starts to go too far when two functions that happen to share a handful of lines become a target for deduplication. The test for whether some pieces of code should be deduplicated is simple: would anything bad happen if one was changed without also changing the other? If the answer is yes, then make a single source of truth for it. If not, consider leaving it alone. - :duck: self-comment : exactly... what I just wrote above :-) > * Avoid configurable functions : Prefer many functions to a few, configurable functions, i.e It’s much better to have multiple functions, each of which does just one thing. > * Don’t prematurely optimize ## being productive - software requirements [Why You Need to Understand Software Requirements as a Software Engineer](https://www.freecodecamp.org/news/why-understanding-software-requirements-matter-to-you-as-a-software-engineer) ## being productive - specifications [What is a "Specification"? • Buttondown](https://buttondown.email/hillelwayne/archive/what-is-a-specification) [Why Specifications Don't Compose • Hillel Wayne](https://hillelwayne.com/post/spec-composition) [Scaffolding TLA+ • Buttondown](https://buttondown.email/hillelwayne/archive/scaffolding-tla) [Steven A. Lowe](https://techbeacon.com/big-benefits-tiny-types-how-make-your-codes-domain-concepts-explicit) (2018) Big benefits from tiny types: How to make your code's domain concepts explicit ## being productive - staying focused [J. B. Rainsberger](http://blog.jbrains.ca/permalink/avoid-distractions-while-programming) Avoiding Distractions While Programming :star: [Dan Milstein](http://blog.hut8labs.com/coding-fast-and-slow.html) (2013) Coding, Fast and Slow: Developers and the Psychology of Overconfidence about inability of developers to predict how long a project will take. [Derek Sivers](https://sivers.org/slow) (2016) I’m a very slow thinker [Aurore Malherbes](https://www.theodo.fr/blog/2017/04/become-a-better-developer-with-an-efficient-technical-watch/) (2017) Become a better developer with an efficient technical watch [Itamar Turner-Trauring](https://codewithoutrules.com/2018/05/20/staying-focused/) (2018) Staying focused, the productive way ## being productive - strategically coding [My manager said I need to have more strategic thinking. Thoughts?](https://old.reddit.com/r/learnprogramming/comments/15c5sob/my_manager_said_i_need_to_have_more_strategic/) [A Binder Full of Questions • Buttondown](https://buttondown.email/hillelwayne/archive/a-binder-full-of-questions) ## being productive - technical debt [Cognitive loads in programming | Hacker News](https://news.ycombinator.com/item?id=32666506) [Infrequent, Pragmatic, Lambda Blog - Cognitive Loads in Programming](https://rpeszek.github.io/posts/2022-08-30-code-cognitiveload.html) [Can't be fucked: Underrated cause of tech debt | Hacker News](https://news.ycombinator.com/item?id=37859311) [Can't Be F*cked: Underrated Cause of Tech Debt - Pursuit Of Laziness - A blog by Jesse Duffield](https://jesseduffield.com/Can%27t-Be-Fcked/) [Tech Debt: My Rust Library Is Now a CDO | Hacker News](https://news.ycombinator.com/item?id=39827645) [On Tech Debt: My Rust Library is now a CDO | Armin Ronacher's Thoughts and Writings](https://lucumr.pocoo.org/2024/3/26/rust-cdo/) [All code is technical debt | Hacker News](https://news.ycombinator.com/item?id=38694051) [All code is technical debt | TokyoDev](https://www.tokyodev.com/articles/all-code-is-technical-debt) [Technical debt as a lack of understanding | Hacker News](https://news.ycombinator.com/item?id=25008587) [Technical debt as a lack of understanding](https://daverupert.com/2020/11/technical-debt-as-a-lack-of-understanding/) [The True Meaning of Technical Debt (2020) | Hacker News](https://news.ycombinator.com/item?id=26791138) [The True Meaning of Technical Debt 💸 - by Luca Rossi](https://refactoring.fm/p/the-true-meaning-of-technical-debt) [Bill Clark](https://technology.riotgames.com/news/taxonomy-tech-debt) (2018) A Taxonomy of Tech Debt [Emiliano Soldi](https://www.linkedin.com/pulse/relentlessly-avoid-technical-debt-emiliano-soldi) Relentlessly Avoid Technical Debt [The HFT Guy](https://thehftguy.com/2020/08/26/technical-debt-doesnt-exist/) (2020) Technical Debt Doesn’t Exist > * Make yourself a favor and call that MAINTENANCE. > * Software do not have a technical debt problem, software simply requires maintenance. [A project with a single 11,000-line code file | Hacker News](https://news.ycombinator.com/item?id=30898803) [The project with a single 11,000-line code file - Austin Z. Henley](https://austinhenley.com/blog/11000lines.html) [We invested 10% to pay back tech debt | Hacker News](https://news.ycombinator.com/item?id=34394351) [We invested 10% to pay back tech debt; Here's what happened](https://blog.alexewerlof.com/p/tech-debt-day) ## being productive - time management [Physical vs Logical Time • Buttondown](https://buttondown.email/hillelwayne/archive/physical-vs-logical-time) [Professional maintainers: a wake-up call | Hacker News](https://news.ycombinator.com/item?id=29523510) [Professional maintainers: a wake-up call](https://words.filippo.io/professional-maintainers/) [Ask HN: What are these low quality "code snippet" sites? | Hacker News](https://news.ycombinator.com/item?id=29403947) [Software reuse is more like an organ transplant than snapping Lego blocks (2011) | Hacker News](https://news.ycombinator.com/item?id=23630640) [LEGO blocks and organ transplants](https://www.johndcook.com/blog/2011/02/03/lego-blocks-and-organ-transplants/) ## being productive - tooling improvements [Developer tools can be magic but instead collect dust | Hacker News](https://news.ycombinator.com/item?id=26612894) [Developer tools can be magic. Instead, they collect dust. | Path-Sensitive](https://www.pathsensitive.com/2021/03/developer-tools-can-be-magic-instead.html) [Digital Tools I Wish Existed | Hacker News](https://news.ycombinator.com/item?id=25228089) [Digital Tools I Wish Existed :: up & to the right - Jonathan Borichevskiy](https://jon.bo/posts/digital-tools/) [Hands-Free Coding: How I develop software using dictation and eye-tracking | Hacker News](https://news.ycombinator.com/item?id=24846887) [Coding with voice dictation using Talon Voice](https://www.joshwcomeau.com/blog/hands-free-coding/) [Ask HN: Programs that saved you 100 hours? (2022 edition) | Hacker News](https://news.ycombinator.com/item?id=34069106) ## being productive - work-life balance [Itamar Turner-Trauring](https://codewithoutrules.com/2016/11/10/work-life-balance-software-engineer/) (2016) Work/life balance will make you a better software engineer [Itamar Turner-Trauring](https://codewithoutrules.com/2017/01/11/your-job-is-not-your-life/) (2017) Staying competitive as a developer [Lewis Menelaws](https://dev.to/lewismenelaws/how-to-fix-burnout-as-a-developer--4opl) (2018) How to Fix Burnout as a Developer > A lot of people (especially entrepreneurs) are so obsessed with how fast they will become successful that they will sacrifice their mental health in order to constantly push themselves. [David Mytton](https://blog.serverdensity.com/humanops-server-density/) How we do HumanOps at Server Density [Jason Fried](https://m.signalvnoise.com/being-tired-isn-t-a-badge-of-honor-fa6d4c8cff4e) Being tired isn’t a badge of honor [Simple Programmer](https://simpleprogrammer.com/) Robert Whitcomb's Blog about soft skills + health & work-life balance for programmers ## do one thing and do it well [Kernighan and Pike were right: Do one thing, and do it well | Hacker News](https://news.ycombinator.com/item?id=37174330) [Kernighan and Pike were right: Do one thing, and do it well | by Keaton Brandt | Source and Buggy | Medium](https://medium.com/source-and-buggy/do-one-thing-and-do-it-well-886b11a5d21) ## egoless programming [WikiWikiWeb](https://wiki.c2.com/?EgolessProgramming) Egoless Programming [Rajasegar Chandran](https://web.archive.org/web/20200203103540/https://hangaroundtheweb.com/2018/03/egoless-programming/) (2018) Egoless Programming > Egoless programming is a concept introduced by Gerald Weinberg in The Psychology Of Computer Programming. The idea is that programmers must fight the natural tendency to treat their programs as part of themselves, and therefore to reject all criticism. Rather, they should do their best to treat their designs & implementations as objects independent of themselves, and to view criticism dispassionately on its merits. [Wikipedia](https://en.wikipedia.org/wiki/Egoless_programming) Egoless programming [Jeff Atwood](https://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/) (2006) The Ten Commandments of Egoless Programming :star: [Daniel Irvine](https://8thlight.com/blog/daniel-irvine/2016/09/30/the-egoless-programmer.html) (2016) The egoless programmer ## finding a mentor [Chris The Data Guy](https://betterprogramming.pub/dont-write-code-for-a-startup-1eead038c372) (2021) Don’t Write Code for a Startup Confessions of a serial startup software developer ## focus on problems [Dan Moore](https://letterstoanewdeveloper.com/2021/01/18/think-first-about-what-problem-this-is-solving-and-for-whom/) (2021) Think first about what problem this is solving and for whom > every time you pick up a new Jira ticket or sit down to complete a new requirement, I suggest that you ask yourself the following questions: > * Who does this solve a problem for? > * What is the problem they’re trying to solve? > * How does this ticket solve it? ## growing in the discipline - 10x dev [Yevgeniy Brikman](https://www.ybrikman.com/writing/2013/09/29/the-10x-developer-is-not-myth/) (2013) The 10x developer is NOT a myth > - If you can’t measure it, you can still reason about it > - 10x programmers are rare > - Programming is about choices [Joe Zack](https://www.codingblocks.net/practice/four-reasons-why-10x-developer-controversial/) (2018) 4 reasons why the “10x Developer” is so controversial > 0 Productivity is hard to measure > 1 Tiny sample size > 2 Well, common sense…. > 3 The study was done over 50 years ago [Yossi Kreinin aka wetware](https://yosefk.com/blog/evil-tip-avoid-easy-things.html) (2016) Evil tip: avoid "easy" things > To a very large extent, [your productivity is a result of what you choose to work on](https://yosefk.com/blog/10x-more-selective.html). Keep things perceived as easy out of that list. When you can't, postponing an "easy" thing can make it both "harder" and smaller. [Yossi Kreinin aka wetware](https://yosefk.com/blog/10x-more-selective.html) (2013) 10x more selective > So I believe, having authored a lot of code that went down the toilet, that you don't get productive by working as much as by not working – not on stuff that is likely to get thrown away. [Meghan Hebel](https://codeburst.io/why-you-dont-deserve-that-dream-developer-job-60d5e5adb8d7) Why You Don’t Deserve That Dream Developer Job [Itamar Turner-Trauring](https://codewithoutrules.com/2016/08/25/the-01x-programmer/) (2016) From 10x programmer to 0.1x programmer: creating more with less [Andrew Payne](https://payne.org/blog/the-myth-of-the-myth-of-the-10x-programmer/) (2020) The Myth of the Myth of the 10x Programmer > * I think 10x developers, like world-class athletes, musicians, and authors, absolutely do exist. You’re just not going to find them with a coding test. > * Highly productive developers (10x or otherwise) are problem-solving at a much higher level. [Itamar Turner-Trauring](https://codewithoutrules.com/2018/08/10/always-more-work-to-do/) (2018) There’s always more work to do—but you still don’t need to work long hours > Whenever you feel yourself with too much work to do, go back and apply these principles: underpromise, limit your own time, prioritize ruthlessly. With practice you’ll learn how to deliver the results that really matter—without working long hours. ## growing in the discipline [Who wrote this shit? | Hacker News](https://news.ycombinator.com/item?id=29874061) [Who wrote this shit? | Philip Heltweg](https://www.heltweg.org/posts/who-wrote-this-shit/) [You are never taught how to build quality software | Hacker News](https://news.ycombinator.com/item?id=38570261) [You are never taught how to build quality software | Florian Bellmann | Be curious, explore and meditate.](https://www.florianbellmann.com/blog/never-taught-qa) [Ask HN: Who else is working on nothing? | Hacker News](https://news.ycombinator.com/item?id=38983067) [How can you not be romantic about programming? (2020) | Hacker News](https://news.ycombinator.com/item?id=26206921) [Thorsten Ball - How can you not be romantic about programming?](https://thorstenball.com/blog/2020/09/08/how-can-you-not-be-romantic-about-programming/) [Show HN: I saw this mind-blowing experiment, so I made a simple version of it | Hacker News](https://news.ycombinator.com/item?id=38413660) [Momciloo/fun-with-sockets](https://github.com/Momciloo/fun-with-sockets) [Things they didn't teach you about software engineering | Hacker News](https://news.ycombinator.com/item?id=34282339) [Things they didn't teach you about Software Engineering](https://vadimkravcenko.com/shorts/things-they-didnt-teach-you/) [Aging programmer | Hacker News](https://news.ycombinator.com/item?id=32961933) [Aging programmer](https://world.hey.com/jorge/aging-programmer-d448bdec) [Things I've learned in my 20 years as a software engineer | Hacker News](https://news.ycombinator.com/item?id=28797485) [20 Things I've Learned in my 20 Years as a Software Engineer - Simple Thread](https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/) [Lessons Learned from Twenty Years of Site Reliability Engineering | Hacker News](https://news.ycombinator.com/item?id=38037141) [Lessons learned from two decades of Site Reliability Engineering](https://sre.google/resources/practices-and-processes/twenty-years-of-sre-lessons-learned/) [Reflections on 10k Hours of Programming | Hacker News](https://news.ycombinator.com/item?id=28086836) [Reflections on 10,000 Hours of Programming](https://matt-rickard.com/reflections-on-10-000-hours-of-programming) [New Grad vs. Senior Dev | Hacker News](https://news.ycombinator.com/item?id=22708094) [New grad vs senior dev | Fabulous adventures in coding](https://ericlippert.com/2020/03/27/new-grad-vs-senior-dev/) [Things I Learned to Become a Senior Software Engineer | Neil Kakkar](https://neilkakkar.com/things-I-learned-to-become-a-senior-software-engineer.html) [Lessons Learned from My Journey as a Self-Taught Developer](https://www.freecodecamp.org/news/lessons-learned-from-my-journey-as-a-self-taught-developer) [What I've Learned in 45 Years in the Software Industry | Hacker News](https://news.ycombinator.com/item?id=25658216) [BTI360 | What I've Learned in 45 Years in the Software Industry](https://www.bti360.com/what-ive-learned-in-45-years-in-the-software-industry/) [Show HN: A Senior Engineer's CheckList | Hacker News](https://news.ycombinator.com/item?id=20914236) [A Senior Engineer's CheckList - Little Blah](https://littleblah.com/post/2019-09-01-senior-engineer-checklist/) [GitHub - littleblah/senior-engineer-checklist: Senior Engineer CheckList](https://github.com/littleblah/senior-engineer-checklist) [My top 25 items in a senior engineer's checklist | by Little Blah! | Medium](https://medium.com/@littleblah/my-top-25-items-in-a-senior-engineers-checklist-c8e9f9f6e3c2) [Software engineering topics I changed my mind on | Hacker News](https://news.ycombinator.com/item?id=25887373) [Software development topics I've changed my mind on after 6 years in the industry - Blogomatano](https://chriskiehl.com/article/thoughts-after-6-years) [Things I Learnt from a Senior Software Engineer | Hacker News](https://news.ycombinator.com/item?id=20794861) [Things I Learnt from a Senior Software Engineer | Neil Kakkar](https://neilkakkar.com/things-I-learnt-from-a-senior-dev.html) [Things I learnt the hard way in thirty years of software development | Hacker News](https://news.ycombinator.com/item?id=20211778) [Drunk Post: Things I've Learned as a Sr Engineer | Hacker News](https://news.ycombinator.com/item?id=27333260) [Julio Biason .Net 4.1 | Things I Learnt The Hard Way (in 30 Years of Software Development)](https://web.archive.org/web/20200124165803/https://blog.juliobiason.me/thoughts/things-i-learnt-the-hard-way/) [What I Wish I Knew as a Junior Dev - Lessons Learned After 11 Years of Coding](https://www.freecodecamp.org/news/lessons-learned-after-11-years-coding) [All the best engineering advice I stole from non-technical people | Hacker News](https://news.ycombinator.com/item?id=20610839) [All the best engineering advice I stole from non-technical people | by Marianne Bellotti | Medium](https://bellmar.medium.com/all-the-best-engineering-advice-i-stole-from-non-technical-people-eb7f90ca2f5f) [Absolute truths I unlearned as junior developer (2019) | Hacker News](https://news.ycombinator.com/item?id=31636812) [Absolute truths I unlearned as junior developer | Hacker News](https://news.ycombinator.com/item?id=20124018) [7 Absolute Truths I Unlearned as Junior Developer](https://monicalent.com/blog/2019/06/03/absolute-truths-unlearned-as-junior-developer/) [My Most Embarrassing Mistakes as a Programmer (so far) - Stack Overflow Blog](https://stackoverflow.blog/2019/10/29/my-most-embarrassing-mistakes-as-a-programmer-so-far) [Peter Naur's view of programming | Hacker News](https://news.ycombinator.com/item?id=26027448) [How to hire senior developers: Give them more autonomy - Hiring Engineers](https://hiringengineersbook.com/post/autonomy/) [A bunch of programming advice I'd give to myself 15 years ago | Hacker News](https://news.ycombinator.com/item?id=40829607) [Marcus' Blog](https://mbuffett.com/posts/programming-advice-younger-self/) [My guiding principles after 20 years of programming (2020) | Hacker News](https://news.ycombinator.com/item?id=30763516) [My guiding principles after 20 years of programming | by Alex Ewerlöf (moved to substack) | Medium](https://alexewerlof.medium.com/my-guiding-principles-after-20-years-of-programming-a087dc55596c) [Software Engineering Stack Exchange](https://softwareengineering.stackexchange.com/questions/44177/what-is-the-single-most-effective-thing-you-did-to-improve-your-programming-skill) What is the single most effective thing you did to improve your programming skills? [Ben Hilburn](https://bhilburn.org/a-keystone-of-success/) What mature engineers do and don't do / what it means to be a mature engineer. [Ganeshwara Herawan Hananda](https://medium.com/@lolski/career-tips-for-young-software-engineers-21f7422ac95e) (2017) 7 Tips On How To Become A Competent Software Engineer [Vadim Kravcenko](http://vadimkravcenko.com/growing-your-interns) (2018) Growing your interns eventually you will become Senior Developers and will need to nurture your own interns. [Seph Gentle](https://josephg.com/blog/what-i-tell-all-new-programmers/) (2014) What I tell all new programmers [Ed Finkler](https://the-pastry-box-project.net/ed-finkler/2014-january-6) (2014) How To Be A Great Developer [Raphael Brugier](http://blog.ippon.tech/5-laws-every-developer-should-know/) 5 laws every developer should know [Sijin Joseph](http://sijinjoseph.com/programmer-competency-matrix/) (2014) Programmer Competency Matrix [Antonio Bello](https://www.raywenderlich.com/167015/learning-techniques-programmers) (2017) Learning Techniques for Programmers, by Programmers [Andrew Wulf](http://thecodist.com/article/lessons_from_a_lifetime_of_being_a_programmer) Lessons From A Lifetime Of Being A Programmer [Ben Hilburn](https://dev.to/bhilburn/on-senior-engineers) On Senior Engineers [John Allspaw](http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/) (2012) On Being A Senior Engineer [Gregg Caines](http://caines.ca/blog/2017/06/04/so-you-want-to-be-a-more-senior-engineer/) (2017) So You Want to Be a More Senior Engineer? [Andrew Wulf](http://thecodist.com/article/your_progress_as_a_programmer_is_all_up_to_you) Your Progress As A Programmer Is All Up To You [Justyna Ilczuk](http://tinystruggles.com/2014/05/13/leveling-up-as-a-software-developer.html) (2014) Leveling up as a software developer [Andrew Wulf](http://thecodist.com/article/what_makes_a_programmer_good) What Makes a Programmer Good? [Philip Reames](https://web.archive.org/web/20160731182553/http://www.philipreames.com/Blog/things-every-practicing-software-engineer-should-aim-to-know/) Things every practicing software engineer should aim to know. [alternative link](http://www.tuicool.com/articles/YvIvMj) [John Sonmez](https://simpleprogrammer.com/2013/08/19/software-development-career/) (2013) 4 Things I Wish I Would Have Known When I Started My Software Development Career [Pierluigi Vernetto](http://www.javamonamour.org/2015/01/end-of-my-32-years-contract-on-osb.html) (2015) End of my 3.2 years contract on a OSB integration project.... lesson learned. some good lessons learned for developers / project management :star: [mr-mig/every-programmer-should-know](https://github.com/mr-mig/every-programmer-should-know) A collection of (mostly) technical things every software developer should know. [GitHub - mtdvio/every-programmer-should-know: A collection of (mostly) technical things every software developer should know about](https://github.com/mtdvio/every-programmer-should-know) [David Albert](https://www.recurse.com/blog/27-fundamental-qualities-of-good-programmers) (2013) Fundamental qualities of good programmers [Patrick Louys](https://patricklouys.com/2017/12/27/become-a-better-developer-in-2018/) (2017) Become a better developer in 2018 [Software Engineering Tips](http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer) (2012) Signs that you're a bad programmer [Itamar Turner-Trauring](https://codewithoutrules.com/2016/04/15/40-hour-programmer/) (2016) Improving your skills as a 9 to 5 programmer [Simon Brown](http://www.codingthearchitecture.com/2018/02/09/todays_software_developers_are_the_ivory_tower_architects_of_tomorrow.html) (2018) Today's software developers are the ivory tower architects of tomorrow ## growing in the discipline - building little apps [Stocketa - An app I designed, built and never launched | Hacker News](https://news.ycombinator.com/item?id=37903489) [Stocketa](https://paulstamatiou.com/stocketa/) [Some tiny personal programs I've written | Hacker News](https://news.ycombinator.com/item?id=30614623) [Some tiny personal programs I've written](https://jvns.ca/blog/2022/03/08/tiny-programs/) [Ask HN: Have you created programs for only your personal use? | Hacker News](https://news.ycombinator.com/item?id=31018836) [/r/tinycode](https://www.reddit.com/r/tinycode/) minimalistic, often but not always simple implementations of just about everything. [An app can be a home-cooked meal (2020) | Hacker News](https://news.ycombinator.com/item?id=38877423) [An app can be a home-cooked meal](https://www.robinsloan.com/notes/home-cooked-app/) ## growing in the discipline - done with coding [How to Know When It's Time to Go | Hacker News](https://news.ycombinator.com/item?id=40962675) [How To Know When It's Time To Go](https://thecodist.com/how-to-know-when-its-time-to-go/) ## how programmers think [If architects had to work like programmers (1995) | Hacker News](https://news.ycombinator.com/item?id=39449424) [If Architects had to work like Programmers](http://www.gksoft.com/a/fun/architects.html) [How does the brain interpret computer languages? | Ars Technica](https://arstechnica.com/science/2021/03/how-does-the-brain-interpret-computer-languages) [Writing maintainable code is a communication skill | Hacker News](https://news.ycombinator.com/item?id=29396515) [Writing Maintainable Code is a Communication Skill - Max Chernyak](https://max.engineer/maintainable-code) [How Developers Think: A Walkthrough of the Planning and Design Behind a Simple Web App](https://www.freecodecamp.org/news/a-walk-through-the-developer-thought-process) [Anything can be a message queue if you use it wrongly enough | Hacker News](https://news.ycombinator.com/item?id=36186176) [Anything can be a message queue if you use it wrongly enough - Xe Iaso](https://xeiaso.net/blog/anything-message-queue/) [The Secret to Why Programmers Say Languages Don't Matter: We Think in Pseudo Code Logic; Implement via Syntax! : learnprogramming](https://old.reddit.com/r/learnprogramming/comments/16ujnzp/the_secret_to_why_programmers_say_languages_dont/) [implementedAsTheUserStoryDescribes : ProgrammerHumor](https://old.reddit.com/r/ProgrammerHumor/comments/17sqwo5/implementedastheuserstorydescribes/) [Suppose I wanted to kill a lot of pilots | Hacker News](https://news.ycombinator.com/item?id=27720912) [Suppose I Wanted to Kill a Lot of Pilots | by EJ | Jul, 2021 | History of Yesterday](https://web.archive.org/web/20210704073409/https://historyofyesterday.com/suppose-i-wanted-to-kill-a-lot-of-pilots-f126bbc756fa) [TLA+ Action Properties • Hillel Wayne](https://hillelwayne.com/post/action-properties) [Xiao Ma](https://medium.com/open-sourced-thoughts/code-life-1a44121290a1) (2015) Code • Life We are already doing these things to our code, why not do them to ourselves? [Michael Foord](https://opensource.com/article/17/5/30-best-practices-software-development-and-testing) (2017) 30 best practices for software development and testing [Ilya Sher](https://ilya-sher.org/2019/05/18/on-information-loss-in-software/) (2019) On Information Loss in Software [Giedrius Majauskas](https://www.majauskas.com/programmer-mindset-5-traits-of-programmers-that-have-a-chance-to-become-good-ones) (2009) Programmer mindset: 5 traits of programmers that have a chance to become good ones [Sonny Van Assche](https://www.ntiative.com/the-10-programmer-personality-types-part-1-of-2/) (2018) The 10 Programmer Personality Types (Part 1 of 2) [Part 2](https://www.ntiative.com/the-10-programmer-personality-types-part-2-of-2/) > I feel very much like the “Ghost-Writer” at times, mixed with "The DIY specialist". But anyway, I feel we are all those types at once, it depends on the day, on the task, on the team we work with. [David Winterbottom](https://codeinthehole.com/lists/little-known-words-relevant-to-software-development/) (2017) Little-known words relevant to software development > Example: VERSCHLIMMBESSERN - (German) to make something worse while attempting to make it better > and many others... [Critical thinking in software development, the word ‘should’, and why you shouldn’t listen to… | HackerNoon](https://hackernoon.com/critical-thinking-in-software-development-the-word-should-and-why-you-shouldn-t-listen-to-563090144331) [The Three Virtues of a GREAT Programmer](http://threevirtues.com/) (2010) Laziness, Impatience and Hubris > Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. > Impatience: The anger you feel when the computer is being lazy. > Hubris: The quality that makes you write (and maintain) programs that other people won't want to say bad things about. ## how programmers think - abstractions [What is Abstraction in Programming - And Why is it Useful?](https://www.freecodecamp.org/news/what-is-abstraction-in-programming) [What is Abstraction in Programming? Explained for Beginners](https://www.freecodecamp.org/news/what-is-abstraction-in-programming-for-beginners) [The Wrong Abstraction (2016) | Hacker News](https://news.ycombinator.com/item?id=23739596) [The Wrong Abstraction - Sandi Metz](https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction) 1. duplication is far cheaper than the wrong abstraction 2. prefer duplication over the wrong abstraction [Christian Maioli Mackeprang](https://techbeacon.com/3-creative-techniques-writing-modular-code) (2018) 3 creative techniques for writing modular code [Gergely Orosz](https://blog.pragmaticengineer.com/talk-first-code-later/) (2019) Talk First, Code Later > the "talk first, code later" approach is an un-intuitive tool that speeds development up and leads to better communication between engineers and teams. > Everyone would have saved so much time, if only we communicated first and wrote code only after. [Ben Northrop](http://www.bennorthrop.com/Essays/2018/the-reality-of-reuse.php) (2018) The Reality of Reuse we're hard-wired to want to make decisions quickly and we take too many shortcuts [Jim Leonardo](https://jimsrulesregardingeverything.com/2017/06/29/dont-repeat-yourself-x3/) (2017) Don't Repeat Yourself x3 [Steve McConnell](http://stevemcconnell.com/articles/why-you-should-use-routines-routinely/) (1998) Why You Should Use Routines, Routinely [Anthony Williams](https://www.justsoftwaresolutions.co.uk/design/duplication.html) (2013) Duplication in Software ## how programmers think - bad habits [Google search](https://www.google.be/search?q=what%20are%20the%20worst%20programming%20practices) what are the worst programming practices ## how programmers think - diagrams and flowcharts [Greg Williams](https://spin.atomicobject.com/2017/02/22/diagrams-as-documentation/) (2017) Diagrams as Software Documentation – When a Picture Says it Best ## how programmers think - states [State machines are wonderful tools | Hacker News](https://news.ycombinator.com/item?id=25601821) [State machines are wonderful tools](https://nullprogram.com/blog/2020/12/31/) [All programming philosophies are about state | Hacker News](https://news.ycombinator.com/item?id=34674814) [All Programming Philosophies Are About State | World of BS](https://www.worldofbs.com/minimize-state/) ## human error [Christian Maioli Mackeprang](https://techbeacon.com/how-terrible-code-gets-written-perfectly-sane-people) (2018) How terrible code gets written by perfectly sane people [Christian Maioli Mackeprang](https://techbeacon.com/app-dev-testing/35-programming-tech-make-your-code-smell) (2018) 35 programming habits that make your code smell ## keeping it simple [Niklaus Wirth, or the Importance of Being Simple | Hacker News](https://news.ycombinator.com/item?id=39004526) [Niklaus Wirth, or the Importance of Being Simple - Communications of the ACM](https://cacm.acm.org/blogcacm/niklaus-wirth-or-the-importance-of-being-simple/) [Niklaus Wirth has died | Hacker News](https://news.ycombinator.com/item?id=38858012) [Bertrand Meyer on X: "We lost a titan of programming languages, programming methodology, software engineering and hardware design. Niklaus Wirth passed away on the first of January. We mourn a pioneer, colleague, mentor and friend." / X](https://twitter.com/Bertrand_Meyer/status/1742613897675178347) [Simple Lasts Longer | Hacker News](https://news.ycombinator.com/item?id=38899922) [Simple lasts longer: making a map stateful using scotch tape and Web Storage API](https://newsletter.pnote.eu/p/simple-lasts-longer) [Applying "make invalid states unrepresentable" | Hacker News](https://news.ycombinator.com/item?id=24685772) [Applying "Make Invalid States Unrepresentable"](https://kevinmahoney.co.uk/articles/applying-misu/) [Loris Cro](https://kristoff.it/blog/simple-not-just-easy/) (2019) I Want Simple, Not Just Easy > You've surely read plenty about how simple is good, but what's wrong with easy? [Daniel Miessler](https://danielmiessler.com/blog/stop-being-proud-of-complexity/) Stop Being Proud of Complexity [Jessica Kerr](https://blog.codeship.com/growing-tech-stack-say-no/) Growing Your Tech Stack: When to Say No [Steve McConnell](http://stevemcconnell.com/articles/keep-it-simple/) (1996) Keep It Simple [Steve McConnell](http://stevemcconnell.com/articles/achieving-leaner-software/) (1997) Achieving Leaner Software [Gordon Brander](http://gordonbrander.com/pattern/second-system-syndrome/) Second System Syndrome a simple system is doomed to be replaced by an excessively abstract, over-engeered, or bloated successor. [Jakub Holý](https://theholyjava.wordpress.com/2016/03/04/dont-add-unnecessary-checks-to-your-code-pretty-please/) (2016) Don’t add unnecessary checks to your code, pretty please! [Morgan Housel](http://www.collaborativefund.com/blog/solving-hard-problems-with-simple-ideas/) (2017) Solving Hard Problems With Simple Ideas [Shane Fast](https://medium.com/paper-engineering/what-a-kids-cartoon-taught-me-about-software-7cbd3bf45c6a) (2017) What a kid’s cartoon taught me about software [Fred Hébert](https://ferd.ca/complexity-has-to-live-somewhere.html) (2020) Complexity Has to Live Somewhere > When dealing with build tools, a few things become apparent: > * if you make the build tool simple, it won't handle all the weird edge cases that exist out there > * if you want to handle the weird edge cases, you need to deviate from whatever norm you wanted to establish > * if you want ease of use for common defaults, the rules for common defaults must be shared between the tool and the users, who shape their systems to fit the tool's expectations > * if you allow configuration or scripting, you give the users a way to specify the rules that must be shared, so the tool fits their systems > * if you want to keep the tool simple, you have to force your users to only play within the parameters that fit this simplicity > * if your users' use cases don't map well to your simplicity, they will build shims around your tool to attain their objectives [Ben Hoyt](https://benhoyt.com/writings/the-small-web-is-beautiful/) (2021) The small web is beautiful > * Fewer moving parts. It’s easier to create more robust systems and to fix things when they do go wrong. > * Small software is faster. Fewer bits to download and clog your computer’s memory. > * Reduced power consumption. This is important on a “save the planet” scale, but also on the very local scale of increasing the battery life of your phone and laptop. > * The light, frugal aesthetic. That’s personal, I know, but as you’ll see, I’m not alone. [Brandur Leach](https://brandur.org/minimalism) (2018) In Pursuit of Production Minimalism ## learning - code exercises and challenges [Any good websites where I can daily exercise in HTML, CSS, JavaScript(not leetcode type) to keep me up to speed/refresh with all the concepts in bits? : learnjavascript](https://old.reddit.com/r/learnjavascript/comments/bollrp/any_good_websites_where_i_can_daily_exercise_in) [Challenging projects every programmer should try | Hacker News](https://news.ycombinator.com/item?id=21790779) [Challenging projects every programmer should try (2019) | Hacker News](https://news.ycombinator.com/item?id=38768678) [Challenging projects every programmer should try - Austin Z. Henley](https://austinhenley.com/blog/challengingprojects.html) [More challenging projects every programmer should try | Hacker News](https://news.ycombinator.com/item?id=25489879) [More challenging projects every programmer should try - Austin Z. Henley](https://austinhenley.com/blog/morechallengingprojects.html) [Challenging algorithms and data structures every programmer should try - Austin Z. Henley](https://austinhenley.com/blog/challengingalgorithms.html) [LOWREZJAM 2019](https://itch.io/jam/lowrezjam-2019) The goal of the jam is to create a game with a resolution of 64x64 pixels or less. You can use whatever programming language or tools that you wish. ## learning - focusing on non-coding things [Woodworking as an escape from the absurdity of software | Hacker News](https://news.ycombinator.com/item?id=40245601) [Woodworking as an escape from the absurdity of software](https://alinpanaitiu.com/blog/woodworking-escape-from-software-absurdity/) [Want an unfair advantage in your tech career? Consume content for other roles | Hacker News](https://news.ycombinator.com/item?id=35040194) [Want an unfair advantage in your tech career? Consume content meant for other roles](https://matthewgrohman.substack.com/p/want-an-unfair-advantage-in-your) [An incomplete list of skills senior engineers need, beyond coding | Hacker News](https://news.ycombinator.com/item?id=27414443) [An incomplete list of skills senior engineers need, beyond coding | by Camille Fournier | Medium](https://skamille.medium.com/an-incomplete-list-of-skills-senior-engineers-need-beyond-coding-8ed4a521b29f) [GitHub - romenrg/evergreen-skills-developers: List of evergreen skills, based on software development best practices & cross-framework principles, that should serve as a fair assessment of skilled software engineers/developers](https://github.com/romenrg/evergreen-skills-developers) [GitHub - jVirus/soft-skills: 🍦List of Soft Skills for software engineers/developers.](https://github.com/jVirus/soft-skills) [GitHub - DorukKorkmaz/soft-skills: Summary of the book Soft Skills: The software developer's life manual by John Sonmez](https://github.com/DorukKorkmaz/soft-skills) [Shubhro Saha](http://www.shubhro.com/2014/12/27/software-engineers-should-write/) (2014) Software engineers should write [Heather Knight](https://hackernoon.com/how-to-solve-programmers-block-18363c040656) What Writers Can Teach Programmers [Itamar Turner-Trauring](https://codewithoutrules.com/2017/10/04/technical-skills-productive/) (2017) Technical skills alone won’t make you productive [John Sonmez](https://talkpython.fm/episodes/show/71/soft-skills-the-software-developer-s-life-manual) (2016) Episode #71: Soft Skills: The software developer's life manual [Ashton Kemerling](https://web.archive.org/web/20181013082216/http://ashtonkemerling.com/blog/2014/06/09/the-swordsman-and-the-software-engineer/) (2014) The Swordsman and the Software Engineer It’s easy to believe that specializing and focusing will make you better than your peers ## learning - focusing on the right skills [Build full "product skills" and you'll probably be fine | Hacker News](https://news.ycombinator.com/item?id=35216894) [John Carmack on X: "From a DM, just in case anyone else needs to hear this. https://t.co/GZl4twl4wP" / X](https://twitter.com/ID_AA_Carmack/status/1637087219591659520) [Focus and Flow: trade-offs in programmer productivity | pseudorandom](https://www.aaronbuxbaum.com/focus-and-flow/) [On Repl-Driven Programming | Hacker News](https://news.ycombinator.com/item?id=25620256) [On repl-driven programming - by mikel evins](https://mikelevins.github.io/posts/2020-12-18-repl-driven/) ## learning - forgetting [379: Forgetting - explain xkcd](https://www.explainxkcd.com/wiki/index.php/379:_Forgetting) [James Routley](https://routley.io/posts/logbook/) (2017) Using a logbook to improve your programming ## learning - from others [Ashton Kemerling](http://ashtonkemerling.com/blog/2012/11/22/the-myth-of-the-lone-hacker/) (2012) The Myth of the Lone Hacker without the effort of countless other engineers, part and full time, their projects would have never made it off the ground. ## learning - knowledge base [How to build a second brain as a software developer | Hacker News](https://news.ycombinator.com/item?id=29188418) [How to build a second brain as a software developer - ♾️ Aseem Thakar](https://aseemthakar.com/how-to-build-a-second-brain-as-a-software-developer/) ## learning - mostly useless skills [Most of my skills are now worth nothing, but 10% are worth 1000x | Hacker News](https://news.ycombinator.com/item?id=35627779) [90% of My Skills Are Now Worth $0 - by Kent Beck](https://tidyfirst.substack.com/p/90-of-my-skills-are-now-worth-0) [Trying new programming languages helped me grow as a software engineer | Hacker News](https://news.ycombinator.com/item?id=33222357) [How Trying New Programming Languages Helped Me Grow as a Software Engineer](https://cichocinski.dev/blog/trying-new-programming-languages-helped-grow-software-engineer) [Thorsten Ball - Learn more programming languages, even if you won't use them](https://thorstenball.com/blog/2019/04/09/learn-more-programming-languages) [Thorsten Ball Home](https://thorstenball.com/) [In defense of blub studies | benkuhn.net](https://www.benkuhn.net/blub) [Itamar Turner-Trauring](https://codewithoutrules.com/2016/10/07/growing-your-toolbox/) (2016) More learning, less time: how to quickly gather new tools and techniques [Mike Crittenden](https://critter.blog/2020/08/14/learning-a-technology-you-dont-need-right-now-is-a-waste-of-time/) (2020) Learning a technology you don’t need right now is a waste of time [Morgan Housel](http://www.collaborativefund.com/blog/conflicting-skill-sets/) (2017) Conflicting Skill Sets [Osman (Ozzie) Ahmed Osman](https://hackernoon.com/just-in-case-vs-just-in-time-learning-c87f61d24360) (2018) Just-In-Case vs. Just-In-Time Learning Should software engineers learn new things “just in case” we need them in the future? Or should we learn the things we need “just in time”, when we realize we actually need them? ## learning - papers [Papers every developer should read at least twice (2009) | Hacker News](https://news.ycombinator.com/item?id=27892076) [Michael Feathers - 10 Papers Every Developer Should Read](https://michaelfeathers.silvrback.com/10-papers-every-developer-should-read-at-least-twice) ## learning - websearching [New learners - please understand that everyone has to google things : learnprogramming](https://old.reddit.com/r/learnprogramming/comments/11i189l/new_learners_please_understand_that_everyone_has) [How to become a programmer, or the art of Googling well | okepi](https://okepi.wordpress.com/2014/08/21/how-to-become-a-programmer-or-the-art-of-googling-well) [Everything I googled in a week as a professional software engineer | Hacker News](https://news.ycombinator.com/item?id=20897278) [Everything I googled in a week as a professional software engineer - localghost](https://localghost.dev/blog/everything-i-googled-in-a-week-as-a-professional-software-engineer/) [Get better at Googling | Hacker News](https://news.ycombinator.com/item?id=26911629) [Use Google like a pro - Marko Denic - Web Developer](https://markodenic.com/use-google-like-a-pro/) [Umer Mansoor](https://codeahoy.com/2016/04/30/do-experienced-programmers-use-google-frequently/) (2016) Do Experienced Programmers Use Google Frequently? [Stack Exchange](https://skeptics.stackexchange.com/questions/18539/has-stack-overflow-saved-billions-of-dollars-in-programmer-productivity) Has Stack Overflow saved billions of dollars in programmer productivity? ## long-term view [Farnam Street](https://fs.blog/2018/10/long-game/) (2018) The Surprising Power of The Long Game ## lots of thinking and creativity [What we can learn from "why" the long lost open source developer · GitHub](https://github.com/readme/featured/why-the-lucky-stiff) [Programming Is Mostly Thinking (2014) | Hacker News](https://news.ycombinator.com/item?id=40103407) [Agile Otter Blog: Programming Is Mostly Thinking](https://agileotter.blogspot.com/2014/09/programming-is-mostly-thinking.html) [Wordle is pretty damn smart in many subtle ways | Hacker News](https://news.ycombinator.com/item?id=30435522) [Wordle is pretty damn smart in many subtle ways | Douglas Vaghetti](https://vaghetti.dev/posts/wordle/) [Graham Lee](https://www.sicpers.info/2018/02/its-about-the-thinking/) (2018) It’s about the thinking [Paul Graham](http://paulgraham.com/head.html) (2007) Holding a Program in One's Head [Florian Beijers](https://medium.freecodecamp.org/looking-back-to-what-started-it-all-731ef5424aec) (2015) A Vision of Coding, Without Opening your Eyes [Mike Crittenden](https://critter.blog/2020/01/28/grinders-vs-thinkers/) (2020) Grinders vs. thinkers ## making decisions [John D. Cook](https://www.johndcook.com/blog/2009/03/19/the-buck-stops-with-the-programmer/) (2009) The buck stops with the programmer ## mental health [Mental health in software engineering | Hacker News](https://news.ycombinator.com/item?id=40001150) [Mental Health in Software Engineering](https://vadimkravcenko.com/shorts/mental-health-in-software-engineering/) [Seth Godin](https://seths.blog/2019/03/busy-is-not-the-point/) (2019) Busy is not the point > We’re supposed to give you a pass because you were full on, all day. Frantically moving from one thing to the other, never pausing to catch your breath, and now you’re exhausted. > Points for successful prioritization. Points for efficiency and productivity. Points for doing work that matters. > No points for busy. [Mike Crittenden](https://critter.blog/2021/04/20/future-you-will-be-as-busy-as-current-you/) (2021) Future-you will be as busy as current-you [Joshua Kerievsky](https://www.linkedin.com/pulse/day-we-stopped-sprinting-joshua-kerievsky/) (2017) The Day We Stopped Sprinting > Our new approach felt more natural and we became more responsive to our customer's needs. We spent less time trying to predict how much work we could get done in a rigid time box, and instead allowed ourselves to work on items that ranged from a few hours to a few days. [Morgan Housel](https://www.collaborativefund.com/blog/making-history-by-doing-nothing/) (2018) Making History By Doing Nothing ## mindset [Microsoft 3D Movie Maker Source Code | Hacker News](https://news.ycombinator.com/item?id=31256676) [microsoft/Microsoft-3D-Movie-Maker: This is the source code for the original Microsoft 3D Movie Maker released in 1995. This is not supported software.](https://github.com/microsoft/Microsoft-3D-Movie-Maker) - discussion about tech docs and version control in comments ## mistakes [What's been your biggest stomach drop mistake in your tech career? : cybersecurity](https://old.reddit.com/r/cybersecurity/comments/16vb19f/whats_been_your_biggest_stomach_drop_mistake_in/) ## passionate about their work [Adam Pittenger](https://medium.com/@apitt24/love-what-you-build-build-what-you-love-9cedbb05e32f) Love what you build. Build what you love. [Laura Klein](https://www.usersknow.com/blog/2015/02/your-job-is-not-to-write-code.html) (2015) Your Job Is Not to Write Code [Marcus Blankenship](https://medium.com/maker-to-manager/why-your-programmers-just-want-to-code-36da9973388e) (2017) Why your programmers just want to code [Steve Pavlina](https://www.stevepavlina.com/blog/2005/01/dont-die-with-your-music-still-in-you/) (2005) Don’t Die With Your Music Still In You [Fagner Martins Brack (fagnerbrack)](https://hackernoon.com/the-angry-programmer-52a93bfcbc3c) (2016) The Angry Programmer How an engineer can be competent and incompetent at the same time [MyBroadband](https://mybroadband.co.za/news/smartphones/246583-how-programmers-learn-to-code.html) (2018) How programmers learn to code What programmers want [Craig Shapiro](http://www.collaborativefund.com/blog/goals/) (2017) Passionate Goals :star: [Carl Hembrough](https://dev.to/carlhembrough/programming-used-to-be-fun) (2017) When programming was no longer fun another story about impostor syndrome [Tom Goodwin](https://www.linkedin.com/pulse/we-dont-need-teach-our-kids-code-them-how-dream-tom-goodwin) We don’t need to teach our kids to code, we need to teach them how to dream [Avdi Grimm](http://www.virtuouscode.com/2014/02/10/the-passion-gospel/) (2014) The Passion Gospel No product or company deserves your passion. You can choose to throw your passion into anything you want, but no project inherently deserves it. ## prototyping [Gregg Caines](http://caines.ca/blog/2009/12/26/the-lost-art-of-prototyping/) (2009) The Lost Art of Prototyping ## pseudocode [Lin Taylor](http://linbug.github.io/programming/2017/10/11/Pseudocode-Programming-fake-it-before-you-make-it/) (2017) Pseudocode Programming: fake it before you make it ## reusable code [John D. Cook](https://www.johndcook.com/blog/2008/05/03/reusable-code-vs-re-editable-code/) (2008) Reusable code vs. re-editable code ## solves impossible problems [A spellchecker used to be a major feat of software engineering (2008) | Hacker News](https://news.ycombinator.com/item?id=34971924) [A spellchecker used to be a major feat of software engineering (2008) | Hacker News](https://news.ycombinator.com/item?id=25296900) [A Spellchecker Used to Be a Major Feat of Software Engineering](https://prog21.dadgum.com/29.html) [Hardest problem in computer science: centering things | Hacker News](https://news.ycombinator.com/item?id=40069599) [Hardest Problem in Computer Science: Centering Things @ tonsky.me](https://tonsky.me/blog/centering/) [Decomplication: How to Find Simple Solutions to "Hard" Problems (2016) | Hacker News](https://news.ycombinator.com/item?id=28744680) [Decomplication: How to Find Simple Solutions to Hard Problems - Nat Eliason](https://www.nateliason.com/blog/decomplication) ## staying ethical [DEV](https://dev.to/jeffreyuvero/what-is-your-personal-programming-ethics-483a) (2018) What is your personal Programming ethics? [ACM Ethics](https://ethics.acm.org/code-of-ethics/software-engineering-code/) (1997) The Software Engineering Code of Ethics and Professional Practice ## the importance of persevering - burnout [Burning out and quitting | Hacker News](https://news.ycombinator.com/item?id=28306750) [Burning out and quitting](https://mayakaczorowski.com/blogs/burnout) [Feynman: I am burned out and I'll never accomplish anything (1985) | Hacker News](https://news.ycombinator.com/item?id=26931359) [Feynman's Nobel Ambition](https://www.asc.ohio-state.edu/kilcup.1/262/feynman.html?repostindays=413) [So I finally sorted out what happened to my brain | Hacker News](https://news.ycombinator.com/item?id=27003207) [Tinker on Twitter: "So I finally sorted out what happened to my brain. I, quite literally, hacked so much, for so long, and without enough breaks... ...that I burned all the glucose out of my brain & gave myself seizures. ___ ⬇️ A thread on a very real & physical occupational hazard for infosec." / Twitter](https://web.archive.org/web/20210606081446/https://twitter.com/tinkersec/status/1388107620574171140) ## the importance of persevering [Tell HN: The loneliness of a pretty good developer | Hacker News](https://news.ycombinator.com/item?id=31438426) [Intelligent Brains Take Longer to Solve Difficult Problems | Hacker News](https://news.ycombinator.com/item?id=36172461) [Intelligent brains take longer to solve difficult problems - News - BIH at Charité](https://www.bihealth.org/en/notices/intelligent-brains-take-longer-to-solve-difficult-problems) [306: Orphaned Projects - explain xkcd](https://www.explainxkcd.com/wiki/index.php/306:_Orphaned_Projects) [Königsberg: Seven Small Bridges, One Giant Graph Problem | by Vaidehi Joshi | basecs | Medium](https://medium.com/basecs/k%C3%B6nigsberg-seven-small-bridges-one-giant-graph-problem-2275d1670a12) ## veteran reflections [Reflections on a decade of coding](https://www.scattered-thoughts.net/writing/reflections-on-a-decade-of-coding/) [Man spends entire career mastering crappy codebase | Hacker News](https://news.ycombinator.com/item?id=36984282) [Man Spends Entire Career Mastering Crappy Codebase](https://taylor.town/entire-career) [Things I've learned in my years as a software engineer (2021) | Hacker News](https://news.ycombinator.com/item?id=34434636) [20 Things I've Learned in my 20 Years as a Software Engineer - Simple Thread](https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/) [Forty years of programming | Hacker News](https://news.ycombinator.com/item?id=37814748) [Forty years of programming](https://fabiensanglard.net/40/index.html) [On the use of a life (2020) | Hacker News](https://news.ycombinator.com/item?id=31981486) [On the use of a life](https://www.daemonology.net/blog/2020-09-20-On-the-use-of-a-life.html) [Steve McConnell](http://stevemcconnell.com/articles/teach-programming-principles-not-tools-and-tips/) (1996) Teach Programming Principles, Not “Tools and Tips” [openjck/best-practices](https://github.com/openjck/best-practices) Programming Best Practices Tidbits : A Collection of quotes and paraphrases for developers from around the web. [timoxley/best-practices](https://github.com/timoxley/best-practices) ## being productive [Becoming a high performing software developer working from your bedroom | Hacker News](https://news.ycombinator.com/item?id=22306337) [Becoming a high performing software developer working from your bedroom](https://web.archive.org/web/20220826223704/https://zephony.com/remote-software-developer-productivity) [How to stay productive in the age of social distancing](https://www.freecodecamp.org/news/staying-productive-in-the-age-of-social-distancing) [Habits of Expert Software Designers | Hacker News](https://news.ycombinator.com/item?id=21191477) [Eight Habits of Expert Software Designers: An Illustrated Guide | The MIT Press Reader](https://thereader.mitpress.mit.edu/habits-of-expert-software-designers/) [How to Become an Outstanding Junior Developer](https://www.freecodecamp.org/news/how-to-become-an-astounding-junior-developer) [What is yak shaving?](https://www.techtarget.com/whatis/definition/yak-shaving) ## clean code [The Clean Code Handbook: How to Write Better Code for Agile Software Development](https://www.freecodecamp.org/news/the-clean-code-handbook/) ## learning [How to rapidly improve at any programming language (2016) | Hacker News](https://news.ycombinator.com/item?id=28577371) [cbui.dev - How To Rapidly Improve At Any Programming Language](https://www.cbui.dev/how-to-rapidly-improve-at-any-programming-language/) [Reading Code Right, With Some Help From The Lexer | by Vaidehi Joshi | basecs | Medium](https://medium.com/basecs/reading-code-right-with-some-help-from-the-lexer-63d0be3d21d) [Vaidehi Joshi - Medium](https://medium.com/@vaidehijoshi) [To learn a new language, read its standard library | Hacker News](https://news.ycombinator.com/item?id=28975453) [To Learn a New Language, Read Its Standard Library - Pat Shaughnessy](https://patshaughnessy.net/2021/10/23/to-learn-a-new-language-read-its-standard-library) - i.e., [understand primitives] ## atomization aka dynamic programming [GitHub - nobodyme/dynamic-programming: A tutorial aimed to give an understanding of common dynamic programming problems](https://github.com/nobodyme/dynamic-programming) ## being productive - clean code [How to Write Clean Code - Tips and Best Practices (Full Handbook)](https://www.freecodecamp.org/news/how-to-write-clean-code) [Want cleaner code? Use the rule of six | Hacker News](https://news.ycombinator.com/item?id=32963021) [Want cleaner code? Use the rule of six](https://web.archive.org/web/20221010132053/https://davidamos.dev/the-rule-of-six/) [Jakub Holý](https://theholyjava.wordpress.com/2011/02/14/clean-code-four-simple-design-rules/) (2011) Clean Code: Four Simple Design Rules – Obligatory Read [How to Write Clean Code – Tips for Developers with Examples](https://www.freecodecamp.org/news/how-to-write-clean-code-tips-for-developers/) ## being productive - distractions [Context switching costs more than we give it credit for | Hacker News](https://news.ycombinator.com/item?id=25817395) [Context switching costs more than we give it credit for.](https://thinkingthrough.substack.com/p/context-switching-cost-more-than) [Multitasking hurts performance and may even damage the brain (2018) | Hacker News](https://news.ycombinator.com/item?id=27042151) [Why Successful People Don't Multitask | LinkedIn](https://www.linkedin.com/pulse/why-successful-people-dont-multitask-dr-travis-bradberry/) [Programmer interrupted: The cost of interruption and context switching (2022) | Hacker News](https://news.ycombinator.com/item?id=35459333) [Programmer Interrupted: The Real Cost of Interruption and Context Switching](https://contextkeeper.io/blog/the-real-cost-of-an-interruption-and-context-switching/) [A trick to reaching flow: Leave your work broken | Hacker News](https://news.ycombinator.com/item?id=35456059) [An On-Ramp to Flow](https://census.dev/blog/an-on-ramp-to-flow) [Software Engineering Radio](http://www.se-radio.net/2018/02/se-radio-episode-317-travis-kimmel-on-measuring-software-engineering-productivity/) (2018) SE-Radio Episode 317: Travis Kimmel on Measuring Software Engineering Productivity ## being productive - habits [How to Set Your Future Self Up for Success with Good Coding Habits](https://www.freecodecamp.org/news/set-future-you-up-for-success-with-good-coding-habits) [How to Use Small and Sustainable Habits to Get Your First Dev Job](https://www.freecodecamp.org/news/how-to-use-small-sustainable-habits-to-get-your-first-dev-job) [The thing standing between procrastination and daily progress is ritual | Hacker News](https://news.ycombinator.com/item?id=28235449) [The Thing Standing Between Procrastination and Daily Progress Is Ritual | by Rosie Spinks | Forge](https://forge.medium.com/the-thing-standing-between-procrastination-and-daily-progress-is-ritual-2823d97ffa47) [Important Coding Habits | Hacker News](https://news.ycombinator.com/item?id=36826755) [The Most Important Coding Habits - PuppyCoding](https://puppycoding.com/2023/07/22/healthy-coding-habits/) ## being productive - hitting a wall [How to Beat Coder's Block - Five Tips to Help You Stay Productive](https://www.freecodecamp.org/news/how-to-beat-coders-block-and-stay-productive) [Take a break | Hacker News](https://news.ycombinator.com/item?id=33139297) [Robin Rendle - Take a Break You Idiot](https://robinrendle.com/notes/take-a-break-you-idiot/) ## being productive - procrastinating [How to do the thing you've been avoiding | Hacker News](https://news.ycombinator.com/item?id=36427849) [How to Do the Thing You've Been Avoiding](https://jasonfeifer.beehiiv.com/p/the-thing-that-seems-like-a-bad-idea-maybe-try-it) ## being productive - slow programming [1x Engineer](https://1x.engineer/) a non-exhaustive list of what qualities make up a 1x engineer. ## being productive - tooling improvements [Rules of thumb for a 1x developer | Hacker News](https://news.ycombinator.com/item?id=23029489) [Rules of thumb for a 1x developer | The Other Mickey Wiki](https://muldoon.cloud/programming/2020/04/17/programming-rules-thumb.html) [How to be a -10x Engineer | Hacker News](https://news.ycombinator.com/item?id=35438068) [How to be a -10x Engineer](https://taylor.town/-10x) [How have you used AI or low-code to benefit your Engineering role?](https://old.reddit.com/r/engineering/comments/15gc43a/how_have_you_used_ai_or_lowcode_to_benefit_your/) [378: Real Programmers - explain xkcd](https://www.explainxkcd.com/wiki/index.php/378:_Real_Programmers) ## coding practice - Advent of Code [Advent of Code 2021 | Hacker News](https://news.ycombinator.com/item?id=29403522) [Advent of Code 2021 | Hacker News](https://news.ycombinator.com/item?id=29292818) [Advent of Code](https://adventofcode.com/) is an Advent calendar of small programming puzzles for a variety of skill sets and skill levels that can be solved in any programming language you like. People use them as a speed contest, interview prep, company training, university coursework, practice problems, or to challenge each other. [GitHub - Bogdanp/awesome-advent-of-code: A collection of awesome resources related to the yearly Advent of Code challenge.](https://github.com/Bogdanp/awesome-advent-of-code) [Placing #1 in Advent of Code with GPT-3 | Hacker News](https://news.ycombinator.com/item?id=33850999) [max-sixty/aoc-gpt: Solve Advent of Code puzzles with GPT-3](https://github.com/max-sixty/aoc-gpt) ## data-oriented programming [Principles of Data Oriented Programming | Hacker News](https://news.ycombinator.com/item?id=24686863) [Principles of Data Oriented Programming | Yehonathan Sharvit](https://web.archive.org/web/20220606174519/https://blog.klipse.tech/databook/2020/09/29/do-principles.html?essence) ## learning - code exercises and challenges [Antonio Bello](https://www.raywenderlich.com/135789/how-to-be-a-better-developer-with-programming-challenges) (2016) How To Be a Better Developer with Programming Challenges [The #100DaysOfCode Challenge, its history, and why you should try it for 2021](https://www.freecodecamp.org/news/the-crazy-history-of-the-100daysofcode-challenge-and-why-you-should-try-it-for-2018-6c89a76e298d) [Proge](https://progegame.com/) Guess the Programming Language ## learning - deliberate practice [How to Use Deliberate Practice to Learn Programming More Efficiently](https://www.freecodecamp.org/news/how-to-use-deliberate-practice-to-learn-programming-fast) [Engineers Need to Write | Hacker News](https://news.ycombinator.com/item?id=35292422) [Why Engineers Need To Write - by Ryan Peterman](https://www.developing.dev/p/why-engineers-need-to-write) [Anki-fy your life | Hacker News](https://news.ycombinator.com/item?id=35209775) [Anki-fy Your Life - About to Learn](https://abouttolearn.substack.com/p/anki-fy-your-life) [Jan Mewes](https://dev.to/janux_de/how-to-pick-up-a-new-technology-in-minimal-time-2i4l) (2018) How to pick up a new technology in minimal time? ## learning - doing small things well [Can you make a basic web app without Googling? I can't | Hacker News](https://news.ycombinator.com/item?id=25961420) [Can you make a basic web app without googling? I can't - Austin Z. Henley](https://web.archive.org/web/20210129194036/https://web.eecs.utk.edu/~azh/blog/webappwithoutgoogling.html) ## learning - hitting a wall [How Developers Stop Learning: Rise of the Expert Beginner (2012) | Hacker News](https://news.ycombinator.com/item?id=23767438) [How Developers Stop Learning: Rise of the Expert Beginner - DaedTech](https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/) ## literate programming [Literate programming](http://www.literateprogramming.com/) is a programming paradigm introduced by Donald Knuth in which a program is given as an explanation of the program logic in a natural language, such as English, interspersed with snippets of macros and traditional source code, from which a compilable source code can be generated. [Literate programming links](http://www.literateprogramming.com/links.html) articles about literate programming