Hello, everyone! I recently read an article by [Addy Osmani], which got me wondering about effective software engineering. He argues that a good engineer is not necessarily an effective one. He outlines 10 traits of effective engineers. This got me thinking about the challenges modern engineers face making it difficult to produce clean, maintainable code rapidly in such envs.
As Kent Beck puts it, 'I'm not a great programmer; I'm just a good programmer with great habits.'
Are you truly an efficient developer? While skill mastery and technology expertise are vital, being a good developer doesn't automatically mean you're efficient.
So, what sets apart an efficient developer? You'll be surprised—it's your key traits and habits.
In every R&D team, there's that standout individual, the rockstar everyone seeks advice from. Typically, these programmers are humble and never label themselves as wizards or high performers and they usually walk bare feet in the office.
Ever wondered how these top developers distinguish themselves?
We've talked with some leading Engineers and compiled a list of the most essential traits and habits to guide you on your journey to becoming a more efficient developer. Let's dive in!
30 Key Traits and Habits for Software Engineers to be Effective
Strive to become a holistic, well-rounded developer. Master skills outside of your comfort zone, If your experience is in a static language, master a dynamic one, and experiment with paradigms from different platforms and frameworks.
Plan your shit, test your shit, and even before submitting a PR, conduct a self-review and refine your work to make it even cleaner. Be skeptical, especially of your own biases.
Choose simple over easy. The fastest path to building the feature can introduce complexity that will haunt the codebase for years to come. Don’t over-architect!
Practice Continuous Feedback during the Dev Cycle. Collect data about your code so you can identify issues before reaching prod, understand test results, and make the right design decisions.
Coding is like writing - you must be concise, clear, and eloquent. Good code is well-documented, great code explains itself.
Choose your abstractions. “There is nothing that can’t be solved by another layer of abstraction” but abstraction carries its own cost.
Enforce boundaries: You're expected to write code like a Renaissance sculptor but against totally unrealistic deadlines, It's up to you to enforce boundaries.
know how to communicate effectively with people. Be open-minded, self-aware, adaptive, and compassionate. Share your knowledge, offer help, and collaborate with your peers. Enjoy teamwork!
Be honest with yourself and management about the progress and challenges, avoid falling into an optimistic bias or portraying a non-realistic picture simply because you feel it would be appreciated.
Embrace criticism. CRs are your most important asset but it takes time and practice to learn how to use them as an effective tool.
Be language/framework/library fluid: The most crucial trait for long-term effectiveness is the willingness and ability to learn and apply new things quickly.
Think twice and do it once. Consider the design and existing code before changing things or adding anything new.
Take pride in your work, love what you do!
Empathize with your clients, fellow developers, PMs, etc. Understand that your needs won't always line up with theirs but you can still work together.
Think about the philosophy of what you’re doing and understand the context of your task fully, if not ask.
Get a second opinion If you are not sure about something.
Be user-centric, try to understand your users’ needs, and always develop with the UX in mind.
Be pragmatic and iterate towards goals. Keep a vision of what you want but understand that it could be a winding road to get there.
Don't let your ego get in the way of thinking about the needs of that business/project/etc, you are hired to work for a business/project/etc.
Don't burn out! Try making your 8-hour day more effective. before trying to compensate with overtime and working over the weekends.
Turn your problems into possibilities, and obstacles to opportunities. These obstacles often carry an embedded lesson or a disguised opportunity.
Break one big problem into multiple small problems that are easily solvable. It helps to understand where you gotta focus more.
Take as much responsibility as you can possibly handle the same with accountability AND NOT ONE BIT MORE.
Find the balance between challenge/growth and work /life.
Dig deeper and deeper over your career into the "why" of what you do, and don't be afraid to change based on the answers you find.Seek feedback: Coding in isolation can cause you to overlook blind spots. Peers and users offer fresh perspectives and highlight areas for improvement.
See the big picture: Consider the time versus value trade-offs, Don't get caught on your small tasks sometimes, which makes it challenging to see the big picture.
Plan your day by reviewing the previous day's work and estimating the trajectory for the next day. Identify how your work contributes to creating value.
Don't fear failure and don't be scared of making mistakes. It can stop you from trying new things and growing as a developer.
Reality Check
In reality, this is what happens, code often ends up as something that can work but is highly unmaintainable, hastily put together as a POC, and then deployed into production without being cleaned up and documented. This is not good for you as a developer or for the business either, especially if it is or becomes a critical piece of infrastructure but remains unapproachable.
So, the question is, how do you deliver better code faster? We truly believe that harnessing Continuous Feedback throughout the dev cycle can help you become a more efficient developer. Knowing what your code is doing and when something goes wrong can help you proactively identify issues within the code before they break your code in production.
We’d love to hear what you think are the key traits for becoming a good developer with great habits:) Shoot me an email.
Top comments (0)