Makes me a little ill that the author thinks Jeff Atwood coined that old-ass joke.
.. Nopes, but it was the quickest reference I could find for the joke. I don't like to put quotes in without the source.
Things I Learnt from a Senior Software Engineer
11–20 of 301 posts
Re: Things I Learnt from a Senior Software Engineer
#12Just 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.
Re: Things I Learnt from a Senior Software Engineer
#13> 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 ne…
> 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
Re: Things I Learnt from a Senior Software Engineer
#14These 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.
Re: Things I Learnt from a Senior Software Engineer
#15Just 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 a…
Interesting. I love the idea of generating documentation from code - it does a lot of things right: Single source of truth (right now we have 3), easier to update when changing code as it's right there.
But I'm not sure everything fits in there. Where do you document processes like how to test stuff that isn't possible to test in a local-dev environment?
Or .. what the IDs that have some business meaning, mean.
Re: Things I Learnt from a Senior Software Engineer
#16The 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.…
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 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 th…
This is awesome (and lots of projects - I love it!)
Re: Things I Learnt from a Senior Software Engineer
#17Makes me a little ill that the author thinks Jeff Atwood coined that old-ass joke.
.. Nopes, but it was the quickest reference I could find for the joke. I don't like to put quotes in without the source.
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.
Re: Things I Learnt from a Senior Software Engineer
#18The 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.…
Exactly what a traditional scientist's notebook is.
Re: Things I Learnt from a Senior Software Engineer
#19Just 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 a…
> If you need to comment on what something is doing, usually you can move that behaviour into a function and test that function.
That's the usual argument, and the counter-argument is always the same: you shouldn't comment the what (though I'll argue there's always exceptions), you should comment the why.
Why are you doing this processing here rather than there? Why do you not apply the usual pattern in this specific case? Why does this code, that will make you want to refactor, has been written like this?
Re: Things I Learnt from a Senior Software Engineer
#20The 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.…
Indeed I have been doing this for all my work for over ten years now and it is one of my favourite things.
I use Day One as I also use it for my personal journal. Plain text is great but I do like being able to add rich content (screenshots for example).
As you say being able to look back and know exactly what you were doing on a particular day is a powerful thing.
I've found that over time I have become a lot better at succinctly explaining the problems I faced and how I made progress with them. It is invaluable, even just over the weekend, in helping me 'reload' my brain when I return to work. It also helped me in communicating more technical subjects to others less technical.
It's a brilliant way to unwind and finish the day. I usually only have to spend 5 minutes on it so it isn't like it is a huge commitment.
I highly recommend everyone at least give it a go for a month and see if it works for you.