Don’t always cut corners
I often hear simplified and extreme takes on social networks: one of them is that you should ship first and iterate later. While there is some truth in it, this is sometimes counterproductive, e.g.:
- If you cut a corner about privacy/compliance, your company may end up being sued, paying a large fine and having to implement time/resources consuming external audits
- Every tech debt has to be paid, so taking a shortcut is more work across a long period of time. If you think about building a large system as a long race in the desert where you have to build the car, it’s better to take some time to build a proper car than head out early with a wobbly one.
- Discipline is how you improve the quality of your code, and if you constantly cut corners around it, you will naturally be more lenient with your code and won’t improve as fast as if you were constantly holding the same bar.
With that being said, there is a balance somewhere, but don’t assume that good engineers always cut corners. The best one I know just spit out high quality code/design quickly on their first try.
As you become more senior, you will also be able to build better estimates, add buffers and push back against unreasonable deadlines, so you will naturally have less corners to cut. Over time, as you get more visibility into the product, sales, etc. you will also be able to properly evaluate the cost of cutting corners vs other alternatives – so these corners cut will be valid/good decisions.