24 ms·

Things I Learnt from a Senior Software Engineer

849 points by neilkakkar 7y ago

neilkakkar 7y ago
Existing discussion on Reddit: https://www.reddit.com/r/programming/comments/cv6tnu/self_post_things_i_learnt_from_a_senior_software/ https://www.reddit.com/r/programming/comments/cv6tnu/self_po...
amzans 7y ago
> Good engineers themselves design systems that are more robust and easier to understand by others. This has a multiplier effect, letting their colleagues build upon their work much more quickly and reliably - How to Build Good Software The advice above is probably one of the things which would have the most impact across all your activities as a developer. When people talk about simplicity in software, they don’t necessarily refer to ease of use or number of lines of code, but instead it’s about how understandable a solution is given their shared knowledge.
- dxhdr 7y ago
  > When people talk about simplicity in software, they don’t necessarily refer to ease of use or number of lines of code, but instead it’s about how understandable a solution is given their shared knowledge. Rich Hickey gave a great talk on the topic of "simple" vs "easy": https://www.youtube.com/watch?v=rI8tNMsozo0 https://www.youtube.com/watch?v=rI8tNMsozo0
- atoav 7y ago
  This is also good advice for other areas, even if you are 100% sure you are the only person to ever lay their eyeballs on what happens behind the curtain. I worked in VFX and film post production and this spirit usually saves yourself a lot of hassle in day to day actions and even more so if you get ill, can’t do the job anymore or decide to split it up. The way I worked in VFX certainly had a big impact on my programming. Some work ethics just make sense.
- jiveturkey 7y ago
  > most impact by far. What's missing is: > easier to understand by others. And by yourself, 6 months later. Anytime a "senior" dev complains to me about "junior" devs, I tell them to review their own code from 6 months ago.
Everlag 7y ago
The referenced idea of a 'human log' is great[0]. I started doing something similar 4 years ago and it eventually evolved from per-project notes into a full diary. Being able to search for 'August 24 2016' and know exactly what I did that day is quite powerful. I encourage anyone to take 10 minutes(or 30...) at the end of the day to write up what they've done. Just a text file with minimal formatting has scaled to 2.6MB of hand-typed text. Though, after a bit, I've tended to shard out specific long-running topics into their own files. [0] https://neilkakkar.com/the-human-log.html https://neilkakkar.com/the-human-log.html
- neilkakkar 7y ago
  Indeed! Thanks Everlag! I think it's been the top productivity hack in my life. Not only did it help me keep my thoughts in check, but it became a solid base for me to bundle other habits on top. If I keep a daily log of stuff (one I look forward to because it's super useful - not just a calendar) , all I have to do is add a new column for a new habit I'm tracking, and everyday I'm forced to put in a Yes or a No, which then snowballs into the "Don't break the chain!".
- acemarke 7y ago
  Yeah, I've been doing this since the start of 2013. Last thing I do each day along with filling out my time card. I usually recap what I worked on, conversations I had, other project / teammate updates, where I left off, stuff I learned or fixed, and where I need to pick up the next day. I used RedNotebook for the first few years, then switched to Boostnote because of its Markdown support and snippet syntax highlighting. One note per day, organized into folders by month. It also is hugely valuable when performance review season rolls around. I can go through the whole year in a few minutes and remind myself of all the tasks I worked on, then summarize those in the "what I did" section.
- mtlynch 7y ago
  I do this on a weekly basis. I used to just do it in a Google Doc, but earlier this year, I wrote an app so I could share my log entries publicly. I've been publishing my weeks since March: https://whatgotdone.com/michael https://whatgotdone.com/michael I tried for a few months to make a business out of it, but there wasn't much interest, so I'm planning to open source the code in the next couple weeks. A bit more about my motivation in creating this: https://mtlynch.io/status-updates-to-nobody/ https://mtlynch.io/status-updates-to-nobody/
Ididntdothis 7y ago
I think this is pretty good. As a pretty senior dev myself I always tell people to have an actual design in mind. Know what you are trying to achieve and when something goes wrong you should be able to explain what you expected the system to do on that situation . A lot of people don’t seem to have a clear mental image of the end goal but are overwhelmed . Of course you should be flexible but you need to know where you want to be in order to make good decisions.
noonespecial 7y ago
I was already forgetting things I learnt. They either became so internalized that my mind tricked me into believing I always knew them, or they slipped my mind. The best time to write a tutorial is as you learn a thing yourself. You learn it better for doing it and others benefit from it more because it automatically comes from a beginners perspective.
ztjio 7y ago
Makes me a little ill that the author thinks Jeff Atwood coined that old-ass joke.
- neilkakkar 7y ago
  .. Nopes, but it was the quickest reference I could find for the joke. I don't like to put quotes in without the source.
  - ggambetta 7y ago
    IMO, an unattributed quote (or attributed to "unknown", or you know, doing slightly more research than "the quickest reference you can find") is better than putting a known-wrong reference.
  - LeonB 7y ago
    Hi Neil. The attribution is correctly given here: https://martinfowler.com/bliki/TwoHardThings.html https://martinfowler.com/bliki/TwoHardThings.html (Hint... it's me.)
    - neilkakkar 7y ago
      Hey Leon, thanks! I've updated the website :)
      - asgeir 7y ago
        Cunningham's law in action. "The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer." https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham%27s_Law https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham%27s...
        LeonB 7y ago
        You know it wasn’t Cunningham who said that? (Just kidding)
honkycat 7y ago
Just to toss in my two cents about testing: Unit tests are for refactoring and declaring behaviour. Additionally, a lot of people have made the same observation: Code that is easy to unit test tends to be more modular and have better architecture. If you are struggling to test a function, think about how you can change your design to make testing easier. It will probably improve your code quality. Integration tests are for finding bugs and exceptions and should be a part of CI/CD. You want both. The more testing the better. Comments: I find comments, outside of docstrings, a smell. Even then: Docstrings often become a substitution for a decent type system, so maybe think about what is happing there as well. Documentation should be generated from your codebase. Otherwise, it will inevitably become out of date as people forget to update it. If you need to comment on what something is doing, usually you can move that behaviour into a function and test that function.
- keithnz 7y ago
  the more testing the better? while having tests at unit and integration levels are good... Test as little as possible/responsible. I think it was Kent Beck who first articulated that, though it was something many people converged on in the early 2000s in the XP world. Of course it doesn't mean test nothing, it's recognizing tests are liabilities (as all code is) and we need to make sure they are serving a purpose otherwise delete them / refactor them to get rid of duplication of testing and overly verbose long winded tests that keep repeating things over and over again and again, saying the same thing repeatedly, doubling up on testing :)
  - galaxyLogic 7y ago
    Wasn't it Kent Beck who came up with Extreme Programming and Test-Driven Development? I think testing was one of the big corner-stones of XP. At what point did that turn into "Test as little as possible"? "Unit tests are one of the CORNER STONES of Extreme Programming (XP)" http://www.extremeprogramming.org/rules/unittests.html http://www.extremeprogramming.org/rules/unittests.html Also see: https://hygger.io/blog/tests-in-extreme-programming/ https://hygger.io/blog/tests-in-extreme-programming/ If development is tests-driven and you should minimize the amount of tests then doesn't that also mean you should minimize the amount of development? Well of course, do not develop more than is needed. But that kind of trivializes the whole agile ideology: "Develop As Little As Possible, that allows you to remain the most Agile" Minimizing the amount of development also minimizes the number of bugs. Sounds like a great concept.
adamnemecek 7y ago
These posts keep repeating the same things. "There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors. - Jeff Atwood" This is not novel, nor insightful. "Premature Optimization Is the Root of All Evil". I've reached a point where every time I hear someone say this, I legitimately ignore everything else they say.
- lazzlazzlazz 7y ago
  You've become that unhelpful curmudgeon you used to dismiss.
- sergiotapia 7y ago
  We all "zed shaw" every once in a while
- LeonB 7y ago
  It's also most definitely not a Jeff Atwood joke.
teddyh 7y ago
> Naming your clusters? Naming them after the service that runs on them is great, till the point you start running something else on them too. We ended up naming them with our team name. This is covered by RFC 1178¹, Choosing a Name for Your Computer (from 1990): Don't choose a name after a project unique to that machine. A manufacturing project had named a machine "shop" since it was going to be used to control a number of machines on a shop floor. A while later, a new machine was acquired to help with some of the processing. Needless to say, it couldn't be called "shop" as well. Indeed, both machines ended up performing more specific tasks, allowing more precision in naming. A year later, five new machines were installed and the original one was moved to an unrelated project. It is simply impossible to choose generic names that remain appropriate for very long. Of course, they could have called the second one "shop2" and so on. But then one is really only distinguishing machines by their number. You might as well just call them "1", "2", and "3". The only time this kind of naming scheme is appropriate is when you have a lot of machines and there are no reasons for any human to distinguish between them. For example, a master computer might be controlling an array of one hundred computers. In this case, it makes sense to refer to them with the array indices. While computers aren't quite analogous to people, their names are. Nobody expects to learn much about a person by their name. Just because a person is named "Don" doesn't mean he is the ruler of the world (despite what the "Choosing a Name for your Baby" books say). In reality, names are just arbitrary tags. You cannot tell what a person does for a living, what their hobbies are, and so on. 1. https://tools.ietf.org/html/rfc1178#page-2 https://tools.ietf.org/html/rfc1178#page-2
- grogenaut 7y ago
  I find that team names change more frequently than responsibility in a large org. Also using a team name makes people assume ownership of decisions with that team. That's why I prefer service name. However I haven't thought much about shared use clusters.
  - neilkakkar 7y ago
    We've had the same name for the past 7 years, so going by the future estimates with no extra useful information, I expect us to have the same team name for 7 more years :P
heinrichhartman 7y ago
> When refactoring and preventing huge-ass PRs: “If I’d have changed all the tests first then I would have seen I had 52 files to change and that was obviously gonna be too big but I was messing with the code first and not the tests.” Is breaking it up worth it? My 2 cents: There are two things to consider: 1. reviewability 2. deployment risk If it takes a colleague 3 days to review your code, your PR is too big. If you panic, on the thought of deploying this ever, your PR is too big. On the other side: - Huge PRs that only change formatting are fine. Easy review. Low risk if properly automated/tested. - Largs PRs that are feature neutral are acceptable as long as they are reviewable. - PRs that refactor 2000LOC, fix 2 bugs and add 3 features are not a good idea.
- einpoklum 7y ago
  The thing is: 1. Some people balk at you making lots of small PRs, because it feels like noise to them. 2. Some people/organizations make you do a lot of work on a separate branch and then want you to PR just once for the final feature you're implementing.
  - lonelappde 7y ago
    1. Commits can be merged/squashed when merged upstream. 2. That's fine, your branch has the series of small PRs that people can review.
- foobarian 7y ago
  There are certain ways to organize large PRs to make them easier to review and deploy. Some examples: - if a large refactor moves code around in addition to changing logic, omit the pure moves from the diff and provide a list of files moved in a description - if a large refactor involves a lot of renaming, or other mechanical manipulation, in addition to a little bit of logic changes, split those apart. That way there will be one large mechanical diff, where you can state in the description, "Yes I changed 500 files and there are 20 pages of diffs but the nature of changes is the same as in the first file." This is vastly easier to review for your peers. - A useful safe deployment trick, when feasible: guard new functionality with a kill switch, as well as some kind of sampling gate (e.g. use new logic only where customer id % 31 == 0). Then when proved remove old code in a followup.
contingencies 7y ago
The main value in software is not the code produced, but the knowledge accumulated by the people who produced it Don't agree with this at all. If you're relying on people to maintain knowledge then you're doing it wrong and setting yourself up for failure. Document the why.
- atoav 7y ago
  accumulated doesn’t allow any qualitative judgement about the way they treat that knowledge. So we shouldn’t assume the worst. I suggest the opposite: if they take their own words seriously and this knowledge is the main value than I’d assume they grow in great lenghts documenting that main value — because it would be (as you rightly noticed) lost.
- BurningFrog 7y ago
  The way I think of it, the knowledge should be in the code. Including the tests. To me that is one of the major goals of any code writing. Some new hire I've never met should have a fair chance of working with this in 6 months.
- lonelappde 7y ago
  Parent didn't say what you claim to disagree with. The documentation is how the knowledge is accumulated. People maintain documentation.
  - contingencies 7y ago
    the code produced I would argue that to any experienced software person, in the context of a project the code means "code and documentation" (containing domain knowledge, implementation history and intent inexorably bound together as one unit). Whereas, the quoted phrase suggests a dichotomous perception.
- tehlike 7y ago
  You are thinking just the running system. The decisions behind why, the quirks of the software, how that all fits together, and the knowledge of why you should do certain things (like monitoring, experiments and whatnot) is important. Good luck documenting all that. Good luck making that document discoverable and readable.
caymanjim 7y ago
> I like a bit of humour in my code, and I wanted to name it GodComponent. No. Just no. Do not ever be funny in code. No one else likes your humor, and it's distracting. (Ignoring the other reasons "GodComponent" is a bad name.)
- cwbrandsma 7y ago
  I needed to wrap the code that handled thread management that I use in Swift. I called the component Threader, and in the comments I mention I named it after the TMNT character Shredder. Two things came from that: I have gotten a chuckle from all the developers I introduced to that code, and no one has forgotten about it. Some humor is useful.
  - xmprt 7y ago
    That's nice when the team is small and everyone knows what the code does, but when new members start joining and you have all these inside jokes/references all over the code, it becomes more cumbersome than anything to explain what it is. I enjoy humor but keep it to a minimum and hopefully don't impact the actual readability.
  - mattkrause 7y ago
    The trick here (and in someone else’s “Thrilla in Mozilla”) is that you don’t need to understand the humor or reference to understand the code. It’s just a nice little bonus, since threader is already a perfectly reasonable[0] name. This is different from insisting that helper functions in brains.c be of type pinkyfunc_t. [0] I was tempted to undercut my own point and write cromulent there instead.
- philwelch 7y ago
  I think it's okay to be funny in test cases. For instance, my test data has included the user-agent string, "The Thrilla In Mozilla".
  - jchook 7y ago
    As long as you don't go into potentially offensive humor
einpoklum 7y ago
> Things I Learnt from a Senior Software Engineer I guess spelling wasn't one of them? But other than that, it's a nice blog post. I like the "human log" suggestion - should really pick that one up. I've been doing that already, but only for my servers...
- whitepoplar 7y ago
  What's wrong with the spelling? He's from the UK.
  - OJFord 7y ago
    I don't know what GP has a problem with, but I don't think the author's British - 'internalize' in the opening paragraph.
    - deleted 7y ago
      [deleted]
    - stan_rogers 7y ago
      The zed disease has, unfortunately, spread.
    - Izkata 7y ago
      Probably "learnt" vs "learned".
- galaxyLogic 7y ago
  > I like the "human log" suggestion What I do is I commit to Git every day and I enter a commit-comment
7532yahoogmail 7y ago
This article is fluff. Presented with a gosh-this-is-cool-isnt-it narrative, nothing here suggests senior engineer. Senior engineers must have a much more nuanced assessment about the interaction between organizational norms, teamwork, and software. There's no penetrating insights here. Software is semi-formal at best and more a hidden Markov chain at best. Indeed the central questions to software engineering are deferred as questions.
OJFord 7y ago
> in my team culture it’s not frowned upon to “snoop behind” people writing code. Whenever I sensed something interesting going on, I’d roll around and watch what was happening. Agh, I'd hate that. In fact if anything interesting had been going on on my screen it would immediately stop, no way I could work with someone watching. I struggle enough at desks with my back to a door or where people walk by, just can't stop myself from being distracted and looking. (It's not that I'm not working, or otherwise doing anything I shouldn't be, it's just.. distracting is the best word I have. It's not where I'd sit in a restaurant, and I've despised not having a choice but to sit at such a desk at work.)
- rbavocadotree 7y ago
  It's also strange in that I don't think I'd get very much out of simply watching anyone work, unless they were also giving live commentary or something.
  - nitrogen 7y ago
    There was an article posted on HN a while back that claimed that the best way for beginners to learn a new skill is to watch an expert just work, without any commentary or explanation. I tried finding a link, but couldn't come up with working search terms on DDG, Goog, or HN.
    - dillonmckay 7y ago
      This was an interesting article about the trend towards robotic surgery and the new methods to gain experience in such an environment. https://hbr.org/ideacast/2019/08/how-robots-and-ai-are-changing-job-training https://hbr.org/ideacast/2019/08/how-robots-and-ai-are-chang...
    - tc7 7y ago
      Really seems like I should be better at golf, then. :tear
    - Bekwnn 7y ago
      Casey Muratori's and Jonathan Blow's streams are pretty great in this regard. Both do low-level gamedev.
ulkesh 7y ago
I like the article. I just wish the senior software engineer also included teaching humility. The article isn't written with any ego, so I commend the author, but it would be ideal for any mentor to also teach what to do when being wrong, making a mistake, costing the company money, etc.
xuesj 7y ago
Good programmer should be good at writing essay.
chaboud 7y ago
“De-risking is the art of reducing risk with the code that you deploy. What all steps can you take to reduce the risk of disaster?” Honestly, I talk about derisking most in two contexts in our projects: schedule, invention. Normally this means that derisking is about frontloading unknowns and finding pivot decisions that reduce the likelihood of getting too far in the wrong direction or accumulating too much uncertainty. I don’t use “risk” too often when talking about fault tolerant code or system design. If you’re taking on “risk” in code, like the chance of a lost message, a race condition, or corrupted data, I’m going to take away the keys. Note: I encounter shoddy “we can go hours without a crash, so it’s good” work more than I’d like to admit. It is possible to know why code and systems fail (and account for it) much more than has become industry norm these days.
sidcool 7y ago
There are other blogs by Neil Kakkar that I really enjoyed, including the one on Human log. It's quite nice and practical. https://neilkakkar.com/the-human-log.html https://neilkakkar.com/the-human-log.html
greyskull 7y ago
> In the end, we went with a database with role access control (only our machines and us can talk to the database). Our code gets the secrets from this database on startup. How does the code get access to the database? I've lived in AWS-land for so long, I don't know how the non-cloud world manages secrets.
aleksgrach 7y ago
Я бы с радостью пообъщялся с инженером-програмиста.
NotUsingLinux 7y ago
The article as the comments here read very strange. Like a place where there is no place for people. There can be space (real physical as well as a culture) for people, lets give team human a try. Please let's not be working drones that optimize towards questionable goals... https://podcasts.apple.com/de/podcast/team-human/id1140331811?l=en&i=1000447434162 https://podcasts.apple.com/de/podcast/team-human/id114033181...
greyhair 7y ago
Requirements matter. Design matters. Data matters. Documentation matters. Source control matters. Defect tracking matters. All source code eventually "wears out" and has to be rewritten.
greenie_beans 7y ago
my mentor writes bad code
- greenie_beans 7y ago
  want to report back that i can't write good code either!
mleonhard 7y ago
> I’ve come to love testing so much that I feel uncomfortable writing code in a codebase without tests. This person became a good engineer in only one year! :)

849 points by neilkakkar 7y ago

Existing discussion on Reddit: https://www.reddit.com/r/programming/comments/cv6tnu/self_post_things_i_learnt_from_a_senior_software/ https://www.reddit.com/r/programming/comments/cv6tnu/self_po...

amzans 7y ago

> Good engineers themselves design systems that are more robust and easier to understand by others. This has a multiplier effect, letting their colleagues build upon their work much more quickly and reliably - How to Build Good Software The advice above is probably one of the things which would have the most impact across all your activities as a developer. When people talk about simplicity in software, they don’t necessarily refer to ease of use or number of lines of code, but instead it’s about how understandable a solution is given their shared knowledge.

dxhdr 7y ago
> When people talk about simplicity in software, they don’t necessarily refer to ease of use or number of lines of code, but instead it’s about how understandable a solution is given their shared knowledge. Rich Hickey gave a great talk on the topic of "simple" vs "easy": https://www.youtube.com/watch?v=rI8tNMsozo0 https://www.youtube.com/watch?v=rI8tNMsozo0
atoav 7y ago
This is also good advice for other areas, even if you are 100% sure you are the only person to ever lay their eyeballs on what happens behind the curtain. I worked in VFX and film post production and this spirit usually saves yourself a lot of hassle in day to day actions and even more so if you get ill, can’t do the job anymore or decide to split it up. The way I worked in VFX certainly had a big impact on my programming. Some work ethics just make sense.
jiveturkey 7y ago
> most impact by far. What's missing is: > easier to understand by others. And by yourself, 6 months later. Anytime a "senior" dev complains to me about "junior" devs, I tell them to review their own code from 6 months ago.

Everlag 7y ago

The referenced idea of a 'human log' is great[0]. I started doing something similar 4 years ago and it eventually evolved from per-project notes into a full diary. Being able to search for 'August 24 2016' and know exactly what I did that day is quite powerful. I encourage anyone to take 10 minutes(or 30...) at the end of the day to write up what they've done. Just a text file with minimal formatting has scaled to 2.6MB of hand-typed text. Though, after a bit, I've tended to shard out specific long-running topics into their own files. [0] https://neilkakkar.com/the-human-log.html https://neilkakkar.com/the-human-log.html

neilkakkar 7y ago
Indeed! Thanks Everlag! I think it's been the top productivity hack in my life. Not only did it help me keep my thoughts in check, but it became a solid base for me to bundle other habits on top. If I keep a daily log of stuff (one I look forward to because it's super useful - not just a calendar) , all I have to do is add a new column for a new habit I'm tracking, and everyday I'm forced to put in a Yes or a No, which then snowballs into the "Don't break the chain!".
acemarke 7y ago
Yeah, I've been doing this since the start of 2013. Last thing I do each day along with filling out my time card. I usually recap what I worked on, conversations I had, other project / teammate updates, where I left off, stuff I learned or fixed, and where I need to pick up the next day. I used RedNotebook for the first few years, then switched to Boostnote because of its Markdown support and snippet syntax highlighting. One note per day, organized into folders by month. It also is hugely valuable when performance review season rolls around. I can go through the whole year in a few minutes and remind myself of all the tasks I worked on, then summarize those in the "what I did" section.
mtlynch 7y ago
I do this on a weekly basis. I used to just do it in a Google Doc, but earlier this year, I wrote an app so I could share my log entries publicly. I've been publishing my weeks since March: https://whatgotdone.com/michael https://whatgotdone.com/michael I tried for a few months to make a business out of it, but there wasn't much interest, so I'm planning to open source the code in the next couple weeks. A bit more about my motivation in creating this: https://mtlynch.io/status-updates-to-nobody/ https://mtlynch.io/status-updates-to-nobody/

Ididntdothis 7y ago

I think this is pretty good. As a pretty senior dev myself I always tell people to have an actual design in mind. Know what you are trying to achieve and when something goes wrong you should be able to explain what you expected the system to do on that situation . A lot of people don’t seem to have a clear mental image of the end goal but are overwhelmed . Of course you should be flexible but you need to know where you want to be in order to make good decisions.

noonespecial 7y ago

I was already forgetting things I learnt. They either became so internalized that my mind tricked me into believing I always knew them, or they slipped my mind. The best time to write a tutorial is as you learn a thing yourself. You learn it better for doing it and others benefit from it more because it automatically comes from a beginners perspective.

ztjio 7y ago

Makes me a little ill that the author thinks Jeff Atwood coined that old-ass joke.

neilkakkar 7y ago
.. Nopes, but it was the quickest reference I could find for the joke. I don't like to put quotes in without the source.
- ggambetta 7y ago
  IMO, an unattributed quote (or attributed to "unknown", or you know, doing slightly more research than "the quickest reference you can find") is better than putting a known-wrong reference.
- LeonB 7y ago
  Hi Neil. The attribution is correctly given here: https://martinfowler.com/bliki/TwoHardThings.html https://martinfowler.com/bliki/TwoHardThings.html (Hint... it's me.)
  - neilkakkar 7y ago
    Hey Leon, thanks! I've updated the website :)
    - asgeir 7y ago
      Cunningham's law in action. "The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer." https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham%27s_Law https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham%27s...
      - LeonB 7y ago
        You know it wasn’t Cunningham who said that? (Just kidding)

honkycat 7y ago

Just to toss in my two cents about testing: Unit tests are for refactoring and declaring behaviour. Additionally, a lot of people have made the same observation: Code that is easy to unit test tends to be more modular and have better architecture. If you are struggling to test a function, think about how you can change your design to make testing easier. It will probably improve your code quality. Integration tests are for finding bugs and exceptions and should be a part of CI/CD. You want both. The more testing the better. Comments: I find comments, outside of docstrings, a smell. Even then: Docstrings often become a substitution for a decent type system, so maybe think about what is happing there as well. Documentation should be generated from your codebase. Otherwise, it will inevitably become out of date as people forget to update it. If you need to comment on what something is doing, usually you can move that behaviour into a function and test that function.

keithnz 7y ago
the more testing the better? while having tests at unit and integration levels are good... Test as little as possible/responsible. I think it was Kent Beck who first articulated that, though it was something many people converged on in the early 2000s in the XP world. Of course it doesn't mean test nothing, it's recognizing tests are liabilities (as all code is) and we need to make sure they are serving a purpose otherwise delete them / refactor them to get rid of duplication of testing and overly verbose long winded tests that keep repeating things over and over again and again, saying the same thing repeatedly, doubling up on testing :)
- galaxyLogic 7y ago
  Wasn't it Kent Beck who came up with Extreme Programming and Test-Driven Development? I think testing was one of the big corner-stones of XP. At what point did that turn into "Test as little as possible"? "Unit tests are one of the CORNER STONES of Extreme Programming (XP)" http://www.extremeprogramming.org/rules/unittests.html http://www.extremeprogramming.org/rules/unittests.html Also see: https://hygger.io/blog/tests-in-extreme-programming/ https://hygger.io/blog/tests-in-extreme-programming/ If development is tests-driven and you should minimize the amount of tests then doesn't that also mean you should minimize the amount of development? Well of course, do not develop more than is needed. But that kind of trivializes the whole agile ideology: "Develop As Little As Possible, that allows you to remain the most Agile" Minimizing the amount of development also minimizes the number of bugs. Sounds like a great concept.

adamnemecek 7y ago

These posts keep repeating the same things. "There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors. - Jeff Atwood" This is not novel, nor insightful. "Premature Optimization Is the Root of All Evil". I've reached a point where every time I hear someone say this, I legitimately ignore everything else they say.

lazzlazzlazz 7y ago
You've become that unhelpful curmudgeon you used to dismiss.
sergiotapia 7y ago
We all "zed shaw" every once in a while
LeonB 7y ago
It's also most definitely not a Jeff Atwood joke.

teddyh 7y ago

> Naming your clusters? Naming them after the service that runs on them is great, till the point you start running something else on them too. We ended up naming them with our team name. This is covered by RFC 1178¹, Choosing a Name for Your Computer (from 1990): Don't choose a name after a project unique to that machine. A manufacturing project had named a machine "shop" since it was going to be used to control a number of machines on a shop floor. A while later, a new machine was acquired to help with some of the processing. Needless to say, it couldn't be called "shop" as well. Indeed, both machines ended up performing more specific tasks, allowing more precision in naming. A year later, five new machines were installed and the original one was moved to an unrelated project. It is simply impossible to choose generic names that remain appropriate for very long. Of course, they could have called the second one "shop2" and so on. But then one is really only distinguishing machines by their number. You might as well just call them "1", "2", and "3". The only time this kind of naming scheme is appropriate is when you have a lot of machines and there are no reasons for any human to distinguish between them. For example, a master computer might be controlling an array of one hundred computers. In this case, it makes sense to refer to them with the array indices. While computers aren't quite analogous to people, their names are. Nobody expects to learn much about a person by their name. Just because a person is named "Don" doesn't mean he is the ruler of the world (despite what the "Choosing a Name for your Baby" books say). In reality, names are just arbitrary tags. You cannot tell what a person does for a living, what their hobbies are, and so on. 1. https://tools.ietf.org/html/rfc1178#page-2 https://tools.ietf.org/html/rfc1178#page-2

grogenaut 7y ago
I find that team names change more frequently than responsibility in a large org. Also using a team name makes people assume ownership of decisions with that team. That's why I prefer service name. However I haven't thought much about shared use clusters.
- neilkakkar 7y ago
  We've had the same name for the past 7 years, so going by the future estimates with no extra useful information, I expect us to have the same team name for 7 more years :P

heinrichhartman 7y ago

> When refactoring and preventing huge-ass PRs: “If I’d have changed all the tests first then I would have seen I had 52 files to change and that was obviously gonna be too big but I was messing with the code first and not the tests.” Is breaking it up worth it? My 2 cents: There are two things to consider: 1. reviewability 2. deployment risk If it takes a colleague 3 days to review your code, your PR is too big. If you panic, on the thought of deploying this ever, your PR is too big. On the other side: - Huge PRs that only change formatting are fine. Easy review. Low risk if properly automated/tested. - Largs PRs that are feature neutral are acceptable as long as they are reviewable. - PRs that refactor 2000LOC, fix 2 bugs and add 3 features are not a good idea.

einpoklum 7y ago
The thing is: 1. Some people balk at you making lots of small PRs, because it feels like noise to them. 2. Some people/organizations make you do a lot of work on a separate branch and then want you to PR just once for the final feature you're implementing.
- lonelappde 7y ago
  1. Commits can be merged/squashed when merged upstream. 2. That's fine, your branch has the series of small PRs that people can review.
foobarian 7y ago
There are certain ways to organize large PRs to make them easier to review and deploy. Some examples: - if a large refactor moves code around in addition to changing logic, omit the pure moves from the diff and provide a list of files moved in a description - if a large refactor involves a lot of renaming, or other mechanical manipulation, in addition to a little bit of logic changes, split those apart. That way there will be one large mechanical diff, where you can state in the description, "Yes I changed 500 files and there are 20 pages of diffs but the nature of changes is the same as in the first file." This is vastly easier to review for your peers. - A useful safe deployment trick, when feasible: guard new functionality with a kill switch, as well as some kind of sampling gate (e.g. use new logic only where customer id % 31 == 0). Then when proved remove old code in a followup.

contingencies 7y ago

The main value in software is not the code produced, but the knowledge accumulated by the people who produced it Don't agree with this at all. If you're relying on people to maintain knowledge then you're doing it wrong and setting yourself up for failure. Document the why.

atoav 7y ago
accumulated doesn’t allow any qualitative judgement about the way they treat that knowledge. So we shouldn’t assume the worst. I suggest the opposite: if they take their own words seriously and this knowledge is the main value than I’d assume they grow in great lenghts documenting that main value — because it would be (as you rightly noticed) lost.
BurningFrog 7y ago
The way I think of it, the knowledge should be in the code. Including the tests. To me that is one of the major goals of any code writing. Some new hire I've never met should have a fair chance of working with this in 6 months.
lonelappde 7y ago
Parent didn't say what you claim to disagree with. The documentation is how the knowledge is accumulated. People maintain documentation.
- contingencies 7y ago
  the code produced I would argue that to any experienced software person, in the context of a project the code means "code and documentation" (containing domain knowledge, implementation history and intent inexorably bound together as one unit). Whereas, the quoted phrase suggests a dichotomous perception.
tehlike 7y ago
You are thinking just the running system. The decisions behind why, the quirks of the software, how that all fits together, and the knowledge of why you should do certain things (like monitoring, experiments and whatnot) is important. Good luck documenting all that. Good luck making that document discoverable and readable.

caymanjim 7y ago

> I like a bit of humour in my code, and I wanted to name it GodComponent. No. Just no. Do not ever be funny in code. No one else likes your humor, and it's distracting. (Ignoring the other reasons "GodComponent" is a bad name.)

cwbrandsma 7y ago
I needed to wrap the code that handled thread management that I use in Swift. I called the component Threader, and in the comments I mention I named it after the TMNT character Shredder. Two things came from that: I have gotten a chuckle from all the developers I introduced to that code, and no one has forgotten about it. Some humor is useful.
- xmprt 7y ago
  That's nice when the team is small and everyone knows what the code does, but when new members start joining and you have all these inside jokes/references all over the code, it becomes more cumbersome than anything to explain what it is. I enjoy humor but keep it to a minimum and hopefully don't impact the actual readability.
- mattkrause 7y ago
  The trick here (and in someone else’s “Thrilla in Mozilla”) is that you don’t need to understand the humor or reference to understand the code. It’s just a nice little bonus, since threader is already a perfectly reasonable[0] name. This is different from insisting that helper functions in brains.c be of type pinkyfunc_t. [0] I was tempted to undercut my own point and write cromulent there instead.
philwelch 7y ago
I think it's okay to be funny in test cases. For instance, my test data has included the user-agent string, "The Thrilla In Mozilla".
- jchook 7y ago
  As long as you don't go into potentially offensive humor

einpoklum 7y ago

> Things I Learnt from a Senior Software Engineer I guess spelling wasn't one of them? But other than that, it's a nice blog post. I like the "human log" suggestion - should really pick that one up. I've been doing that already, but only for my servers...

whitepoplar 7y ago
What's wrong with the spelling? He's from the UK.
- OJFord 7y ago
  I don't know what GP has a problem with, but I don't think the author's British - 'internalize' in the opening paragraph.
  - deleted 7y ago
    [deleted]
  - stan_rogers 7y ago
    The zed disease has, unfortunately, spread.
  - Izkata 7y ago
    Probably "learnt" vs "learned".
galaxyLogic 7y ago
> I like the "human log" suggestion What I do is I commit to Git every day and I enter a commit-comment

7532yahoogmail 7y ago

This article is fluff. Presented with a gosh-this-is-cool-isnt-it narrative, nothing here suggests senior engineer. Senior engineers must have a much more nuanced assessment about the interaction between organizational norms, teamwork, and software. There's no penetrating insights here. Software is semi-formal at best and more a hidden Markov chain at best. Indeed the central questions to software engineering are deferred as questions.

OJFord 7y ago

> in my team culture it’s not frowned upon to “snoop behind” people writing code. Whenever I sensed something interesting going on, I’d roll around and watch what was happening. Agh, I'd hate that. In fact if anything interesting had been going on on my screen it would immediately stop, no way I could work with someone watching. I struggle enough at desks with my back to a door or where people walk by, just can't stop myself from being distracted and looking. (It's not that I'm not working, or otherwise doing anything I shouldn't be, it's just.. distracting is the best word I have. It's not where I'd sit in a restaurant, and I've despised not having a choice but to sit at such a desk at work.)

rbavocadotree 7y ago
It's also strange in that I don't think I'd get very much out of simply watching anyone work, unless they were also giving live commentary or something.
- nitrogen 7y ago
  There was an article posted on HN a while back that claimed that the best way for beginners to learn a new skill is to watch an expert just work, without any commentary or explanation. I tried finding a link, but couldn't come up with working search terms on DDG, Goog, or HN.
  - dillonmckay 7y ago
    This was an interesting article about the trend towards robotic surgery and the new methods to gain experience in such an environment. https://hbr.org/ideacast/2019/08/how-robots-and-ai-are-changing-job-training https://hbr.org/ideacast/2019/08/how-robots-and-ai-are-chang...
  - tc7 7y ago
    Really seems like I should be better at golf, then. :tear
  - Bekwnn 7y ago
    Casey Muratori's and Jonathan Blow's streams are pretty great in this regard. Both do low-level gamedev.

ulkesh 7y ago

I like the article. I just wish the senior software engineer also included teaching humility. The article isn't written with any ego, so I commend the author, but it would be ideal for any mentor to also teach what to do when being wrong, making a mistake, costing the company money, etc.

xuesj 7y ago

Good programmer should be good at writing essay.

chaboud 7y ago

“De-risking is the art of reducing risk with the code that you deploy. What all steps can you take to reduce the risk of disaster?” Honestly, I talk about derisking most in two contexts in our projects: schedule, invention. Normally this means that derisking is about frontloading unknowns and finding pivot decisions that reduce the likelihood of getting too far in the wrong direction or accumulating too much uncertainty. I don’t use “risk” too often when talking about fault tolerant code or system design. If you’re taking on “risk” in code, like the chance of a lost message, a race condition, or corrupted data, I’m going to take away the keys. Note: I encounter shoddy “we can go hours without a crash, so it’s good” work more than I’d like to admit. It is possible to know why code and systems fail (and account for it) much more than has become industry norm these days.

sidcool 7y ago

There are other blogs by Neil Kakkar that I really enjoyed, including the one on Human log. It's quite nice and practical. https://neilkakkar.com/the-human-log.html https://neilkakkar.com/the-human-log.html

greyskull 7y ago

> In the end, we went with a database with role access control (only our machines and us can talk to the database). Our code gets the secrets from this database on startup. How does the code get access to the database? I've lived in AWS-land for so long, I don't know how the non-cloud world manages secrets.

aleksgrach 7y ago

Я бы с радостью пообъщялся с инженером-програмиста.

NotUsingLinux 7y ago

The article as the comments here read very strange. Like a place where there is no place for people. There can be space (real physical as well as a culture) for people, lets give team human a try. Please let's not be working drones that optimize towards questionable goals... https://podcasts.apple.com/de/podcast/team-human/id1140331811?l=en&i=1000447434162 https://podcasts.apple.com/de/podcast/team-human/id114033181...

greyhair 7y ago

Requirements matter. Design matters. Data matters. Documentation matters. Source control matters. Defect tracking matters. All source code eventually "wears out" and has to be rewritten.

greenie_beans 7y ago

my mentor writes bad code

greenie_beans 7y ago
want to report back that i can't write good code either!

mleonhard 7y ago

> I’ve come to love testing so much that I feel uncomfortable writing code in a codebase without tests. This person became a good engineer in only one year! :)