I'm starting my new job tomorrow. One of the things that I've done this week is take a look at all the things which I hold for obvious now, even though I believed the complete opposite before my last job 4.5 years ago.
This is going to be more relevant to big tech companies engineers. Anyway, here goes:
1) ask for help early. You don't get extra credit for doing something all by yourself. There's little point in looking for a solution for hours or days when someone you know can unstuck you in minutes.
corollary: helping others is one of the tasks with the highest ROI, and if you're an expert at something you should position yourself so your advice can be easily found.
2) #1 skillset for an engineer is not a specific technical expertise, but the ability to learn.
Learning is not memorizing or knowing syntax. it's being aware of the state of the art and of the current pain points of development so that new solutions make sense.
Learning is not memorizing or knowing syntax. it's being aware of the state of the art and of the current pain points of development so that new solutions make sense.
3) Always have a focus and clear priorities in your work. There are always opportunities to take on side projects or volunteer that seem like "doing more" or going above and beyond. But it's infinitely better to do 100% of what you're expected to do, than do 10% of 10 projects.
4) The goal of code review is not approval, but critique. Same goes for technical documents, presentations, ideas etc. Seek people that will disagree with you rather than just let you proceed.
One thing that really helps the quality of code reviews is detailed commit/diff messages. One way to achieve that is to set up your favorite text editor as default terminal editor (see stackoverflow.com/questions/3331… for instance)
5) Most tests are useless and many are counterproductive.
Tests are useless if they fail to capture the problems they were designed to catch, they are counterproductive if on top of that they require a lot of maintenance / rework to keep passing for any code refactor.
Tests are useless if they fail to capture the problems they were designed to catch, they are counterproductive if on top of that they require a lot of maintenance / rework to keep passing for any code refactor.
6) There are many ways to optimize code. You should know what you optimize for. In my experience of the past 4.5 years: 90% of the time I optimized for maintainability/legibility, 5% for performance (speed), 5% for memory.
That said:
- there are often massive performance gain opportunities that don't have a tradeoff. It's always a good idea to wonder - isn't there anything simple that can make my code go faster?
- there are often massive performance gain opportunities that don't have a tradeoff. It's always a good idea to wonder - isn't there anything simple that can make my code go faster?
- about half of my projects, which were all built to "stand the test of time", were deprecated within a year. So there's something to be said about over-engineering. Sometimes hacky solutions are fine especially on isolated problems.
- there is never a good reason to compromise on code legibility.
- something I never sought as a priority (I always kind of got it as a byproduct of something else), but which can yield massive benefits, is developer comfort. It can make a lot of sense to make tradeoffs on the rest (speed, size etc.) just so life of developers can be easier.
7) When working on a new/unusual problem, instead on focusing on a bespoke solution, ask yourself: is there a way to generalize this problem? and if so, is it possible to come up with a generic solution? and would that make sense?
coming up with a generic solution to a class of problems can yield massive value. However, most of the times, it is not worth it. The costs of making a higher-level solution are significant but the applications are uncertain.
That's it for now. I'm looking forward to change my mind on more things in the years to come!
