15 August 2015, 23:34
Right attitude. You don’t want to work with guys who think they know it all but don’t. Being humble is the key thing. [...] constantly looking for new stuff, absorbing new knowledge, wanting to learn off other people, the desire to do the best thing you can.
Write less code. [...] no unnecessary logic, don’t write stuff that doesn’t need to be said, don’t write verbose code. Don’t make abstracts interfaces, don’t make deep hierarchies that don’t need to be extended, if you don’t need to extend them.
Communicate effectively. Code is communication. You’re communicating not just to the computer, you are communicating to other people writing the code. Even if you are working by yourself, you are communicating to yourself in two years time when you pick up the same section of code. It’s a skill, and it’s something you learn, and it’s something you consciously practice.
Avoid unnecessary complexity. The reason people pay us to write software, [...] is because there’s a complicated problem that needs to be solved. There is some necessary level of complexity in software engineering and we have to embrace and understand. The problem is the unnecessary complexity. [...] One thing I know about well crafted software that basically has the necessary complexity but none of the unnecessary complexity is when I look at it, it looks obvious.
Swallow your pride. The most important thing is when you get into your codebase, is to ask people. I see so many developers who just won’t sort of swallow their pride and say, "I don’t quite know what this is doing, but I know Fred over there does. I’ll just go talk to Fred about it." Often those little bit of insights give you a super fast route through something intractable, a little explanation sort of takes you in there. [...] we truly believe everyone did the best they could to the best of their abilities at the time given what they knew, etc., etc. This stops you from making judgement calls [...]. This teaches you humility to look a little deeper first.
Keep your skill up tu date. If you don’t want to become a coding dinosaur you probably won’t, because you care about it enough that you will learn, you will read, you will spend time, you will look at web casts, whatever. If you don’t have the motivation to do it, that’s when you stagnate. That’s when you become a dinosaur.
A senior developer:
A senior developer is intimately familiar with their own failure. [...] They are reflective about the things that they do, evaluating their successes and failures when approaching problems with intellectual honesty.
A senior developer has fallen out of love of the complexity [...] and is obsessed with simplicity.
A senior developer stops classifying developers based on their knowledge, and instead understands that there is a spectrum of strengths and weaknesses. They [...] strive to play to their own strengths whenever possible.
A senior developer thinks in terms of “context” when applying theory. They understand that there is no “Right Way” to build software, and that the only way to build good software is by adapting theory to fit the needs of the client, codebase, team, tools, and organization.
A senior developer understands that everything in our field involves tradeoff.
A senior developer thinks of more than just themselves. They are aware of how their organization and their clients work, what their values are, and what is both important and not important for success.
A senior developer will understand that this job is to provide solutions to problems, not write code.
[...] a senior developer will take a step back and question what is breaking down to cause all that boring work to begin with. They will evaluate the cost of fixing root problems, and [...] fix them.
A senior developer understands that you cannot do everything yourself, and that their primary role is to help their team get better.
A senior developer understands that leadership is not about power, it is about empowerment. It is not about direction, it is about serving.