I strongly believe you should invest into automatically formatting your code, because beyond esthetic reasons, having code automatically formatted allows:
- To reduce the cognitive overhead for engineers – you can just write code that compiles and it will be automatically styled, e.g. you don’t have to worry about whitespace issues. Code is easier to read too, it’s more consistent.
- To ease large scale refactoring – you can manipulate a large code base without having to build a complete parser since you can rely on formatting rules. E.g. this just happened for me where I wanted to manipulate bazel files at scale and rather than parsing starlark, I could just sequence a few dumb regexes and rely on the fact that kwargs were ordered.
On style itself, I personally don’t have a lot of opinions beside that:
- The code should be readable
- The code should be automatically formatted – I don’t want to run into failing tests because of style or have to manually run commands, just make this part of a pre-commit git hook.
- There’s as much as possible a single valid format for a given file
This is one thing Google got right with Go in my opinion
LinkedIn post
There’s the myth that engineers want to constantly refactor for esthetic reasons and that PMs must constantly fight such efforts. My experience is that this is a terrible dynamic:
- You, as an engineer, should refactor code as you see fit – you are free to take shortcuts and hack things for a quick launch, but you’re ultimately the owner of your code. If you pile terrible hacks, they will eventually break and you’ll be on the hook to maintain and clean it up. Large refactoring is always the result of a plethora of minor refactorings not being done.
- You, as an engineer, are responsible for shipping features fast – so you have to balance tech debt with time to ship. If your goal is to have a perfect and shiny system, you won’t be able to deliver well for the company. The answer is that you should have some amount of tech debt and have to figure out what the right amount is
A few consequences of the above:
- You have to find the right balance between cutting corners and long term productivity. Be reasonable, gather data from other stakeholders (product, sales etc.) to do the right trade-offs at the company level – if you don’t, someone else will and the decision might be sub-optimal for the company
- If you want to truly prove that you can lead a large system in a complex and constantly evolving landscape, you have to stick to your system for longer than a year or two – this is why it’s hard to evaluate a candidate that job hop every 2 years, it’s unclear if their work was actually good and/or if they can maintain/evolve a large scale system.
Last but not least, the optimal amount of tech debt will evolve over time – e.g. the cost of tech debt in a small startup is smaller than in a large company that has a large engineer org and tons of systems/products. This is why it’s important for you to understand companies (and other functions) priorities when deciding when to hack and/or refactor.
LinkedIn post
One issue that plagues many companies is when they use waterfall processes – e.g. the engineer wait for the perfect design doc from their TL, their TL waits for the perfect PRD from their product manager, and their product manager waits for customer feedback, etc. and somewhere a manager waits for the quarter to end 😅
This is a cultural issue and can kill companies. Everyone here can improve the situation by working in parallel, being OK with imperfect design/features (you have to keep iterating on it though) and having efficient/real time communication channels.
The only thing you should be careful is about single-way doors – if you need to make a technical decision that you won’t be able to revert, this is the only case where you may want to (gently) hit the brakes.
The truth is that even if you get the perfect PRD, design doc etc., you may still have to alter the course of your project because of changing priorities (e.g. new important customers requesting new features), new external regulations, changing competitive landscape etc. So staying flexible and able to iterate is the most important feature of yourself/your team/your company.
LinkedIn post
One of the most common “complaints” I hear from engineers is the lack of scope or opportunities. In growing companies, my 2 cents is that the problem isn’t the lack of opportunities, but whether you are able to recognize and grasp them.
It’s a bit hard to provide an exhaustive list of where the opportunities might be for you, but in general if you look back at what you have worked on and try to make it your space – e.g. develop a strong ownership on that domain, you will find impactful work. Here are some examples that may help:
- If you worked on making the release process better and are now able to release once a week, the question would be “why not every day?” What’s missing to be able such cadence – this is where you will find tons of opportunities, maybe you lack regression testing, a read only environment where you can tee traffic, more detailed monitoring (e.g. can you automatically find new error messages in STDERR? Can you classify every error in your servers?
- If you worked on a legacy server to fix some issues, what would it take to either delete it or make it a first class citizen? Can the new server even properly handle the old traffic? If you are stuck with old clients, can you build a shim to forward traffic to the new server?
- If you worked on a new product feature, what prevented shipping it a few X times faster? What infrastructure was missing? Was the review process too slow? Was the release too infrequent? Was the code too tricky that required multiple rounds of fix?
The TL;DR is that if your company is growing, there are things to do – in many large tech companies, staffing is the bottleneck. For what it’s worth, staff software engineers are supposed to own their space and be able to figure out what to work on – if this is your goal, this is a skill you have to develop
LinkedIn post
