What Makes a Good Software Developer?

10 May 2014. comments

I spend a lot of time talking about the craft of software development. What makes a good software developer? This is a list of things I know that I feel make for great developers.

  • Get feedback early and often.
  • Develop incrementally and iteratively. Have tight feedback loops based on small deliverables.
  • Do code reviews for others and get your code reviewed. You need outside feedback to know where you need improvement, and doing code reviews for others will let you see how others do things.
  • Pair program for tighter outside feedback.
  • Read. Lots. There’s a good post over at stackoverflow that lists some of the better ones.
  • Read software development blogs, listen to software development podcasts, and/or follow software developers on twitter. Most of the current trends and tech can be learned by staying up to date with these resources.
  • Learn a new language. There are other paradigms out there and you’ll understand more by knowing another language. Functional, OO, procedural, dynamic, static, etc.
  • Connect with other software developers. The difficult part about software development is communication. You cannot grow as a software developer without interacting with your peers.
  • Participate in sites like StackOverflow, Programmers Stack Exchange, or Parley.
  • Attend user groups or conferences for whatever language or software engineering aspect interests you.
  • Know the great software developers that came before you and stand on their shoulders. Understand the history of the industry so that you don’t repeat it’s past mistakes.
  • Follow the Unix Philosophy.
  • Thoroughly understand the concepts of loose coupling and tight cohesion.
  • Practice TDD (Test Driven Development) both as a design tool and a way to be confident about your code.
  • Understand the principle of least privelege. This is true for both encapsulation as well as security.
  • Don’t use exceptions except in exceptional cases. Exceptions should never be used for ordinary flow control.
  • Project estimation is hard. Don’t make a mess just to meet a schedule.
  • Don’t accumulate technical debt by kidding yourself that you’ll clean things up later.
  • K.I.S.S. (Keep It Simple Stupid). Don’t over-think a problem. Favor the simpler solution over the complex one.
  • Don’t optimize code up front. Benchmark and optimize only when data proves that you need to.
  • Write code for the other humans who will maintain the code; not for the compiler. Readability of code is more amenable to change.
  • Refactor mercilessly, but do it continuously instead of refactoring just to refactor.
  • Use comments sparingly and only when you can’t articulate whats going on with code. Code should be self-documenting when possible.
  • Name variables and types in an obvious manner. Don’t abbreviate or shorten variable names when a full and easy to understand name will communicate better.
  • Don’t reinvent the wheel. If there is a quality software component or framework that will accomplish what you need, then use it.
  • Use the right tool for the job. This is true for the programming language, the tools, the frameworks, everything.
  • The code exists for solving a problem, not for itself. Recognize what adds value to your problem and what does not. Do not build castles in the clouds. Y.A.G.N.I. (You ain’t gonna need it.)
  • Favor convention over configuration. A system does not scale in power relative to the number of knobs and dials you include.
  • Use abstractions but understand what they are doing. You don’t need to know all the nitty gritty details but you should at least should know enough to recognize the benefits and trade-offs of using the abstraction.

comments

Tagged: software craftsmanship career software engineering

2017 Ben Lakey

The words here do not reflect those of my employer.