Effective Software Engineers
What do you think of when you think of effective software engineers? Do you think of things like knowledge of frameworks, libraries, and technologies, an understanding of Big O notation and data structures, or maybe the ability to write code fast? I know a lot of people go in that direction when they think of effective engineers. While I agree that those things are important to being a good programmer, I think being a good engineer, software or otherwise, requires an entirely different set of skills.
As I said just last week, and 6 months ago, software engineering is a social activity. Not just in how you debug and ask questions, but how you work with those around you. Your peers. Your stakeholders. Your customers. Your downstream dependencies. The people who will be maintaining what you’re writing. Your future self.
Which leads me to this article on What Makes An Effective Software Engineer. It goes through a list of things to do (and not do).
Look at that list. None of them are specific to writing code, or even software development in general. Instead, they’re about the traits needed to work well with all of the people involved.
I’n not going to talk about all of them, but here’s a little something about the ones that really resonate with me.
It all starts with the customer. Caring about the customer. Knowing what problem you’re solving and why. It’s about adding value for the user, whoever that is.
Keeping things simple goes along with thinking about the long term. Don’t do things you don’t need yet. Make it simple and easy to change. It’s an iterative process and you learn what you need to do by doing it, so keep it simple, allowing for the long term things when you’re ready for them.
Leaves things better than you found them. The boy scout’s rule. Learn as you go. Make it simpler as you understand more about the domain. Refactor to make it easy to make the change (this can be hard), then make the change. Make things easier for the maintainer
And finally, you need to communicate well. You don’t ever want to surprise someone. New things are explained well. Every change, every decision, internally and externally visible, has not just a what, but a why. You won’t always have agreement, but you should have consensus, and you DO make sure everyone is on the same page.
Check out the article. 10 things you need to be an effective software engineer, but (almost) nothing at all about writing code. In fact, the only place there’s mention of coding and code practices is in the anti-patterns.
