3 ms·
> I've never used these technologies like Kubernetes, Docker etc and feel out of place. Don't get hung on technologies for technologies sake. Kubernetes, Docke
by golergka 6y ago
> I've never used these technologies like Kubernetes, Docker etc and feel out of place.
Don't get hung on technologies for technologies sake. Kubernetes, Docket are just tools that are useful in some contexts and are completely irrelevant in others. The fact that a significant portion of HN is engaged in modern web backend development doesn't mean it's the only significant area of engineering.
> So, how do I write better code?
Short answer: be lazy and hate work.
Fixing bugs is work. Instead of just fixing it, find out how you could've used the type system or API design to prevent yourself from making this bug in the first place. Fixing this bug is work. Preventing yourself from making the bug in the first place is saving yourself of doing the work.
Rewriting your old code when you get new requirements is work — learn how to build an app architecture that would make this amount of work minimal.
Writing code is work. Maintaining code is work. If you manage to complete your tasks using less code, you'll have less work.
Manual testing is work. Writing unit tests is saving your time. Learning how to write tests so you won't have to rewrite them when your requirements change reduces the amount of work you have to do even more. And leveraging the type system to maintain some invariants about your code saves you even more work.
Communicating with your colleagues and answering their questions is work. So, learn how to write code that is easy to understand. Writing comments is work too, so if you manage to write a code that is so clear that it doesn't need comments, you'll save yourself from even more work. Writing great documentation will save you time on work chats.
Of course a big difference between being lazy and being irresponsible. We should always thrive to achieve the best possible result for our customers, internal or external. But actively trying spend less effort without compromising on quality is the best driver for innovation and learning, in my experience.