I spend a lot of time talking about the craft of software development. So what do I think makes a good software developer?
Do you just go pick up an undergrad degree and you’re done? Of course not. At that point you know mechanical technique, without the deeper understanding of how to make good software.
The truth of the matter is that undergrad degrees are really just the primer. They teach you that to make sounds come out of the cello, you must draw the bow across its strings; But they don’t teach you how to make amazing sounds. In order to create amazing software you have to read about the craft, play with languages, try new patterns, keep up with the industry, and be passionate about writing reusable and highly-maintainable code.
So this is my list of the things that make a really great software developer, in no particular order.
- Read. Lots. There are certain books that I would almost consider required reading.
- Code Complete by Steve Mcconnell – This book is the bible of software engineering. The principles and practices taught in these pages form the core of what it means to write quality software.
- The Mythical Man Month by Fredrick P. Brooks – All about software project management. Adding manpower to a late software project makes it later.
- Design Patterns by the Gang of Four – The cookbook of amazing design patterns and their practical usage.
- The C Programming Language by Kernighan and Ritchie – The root of modern programming languages, as told by the creators.
- Code by Charles Petzold – The complete stack from low level all the way up.
- Read software engineering blogs. Here are some good ones for .NET:
- 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. This can include:
- Code reviews
- Pair programming
- Software engineering discussions with friends
- Participate in sites like Stackoverflow.com, Programmers, etc
- Attend a local user group for whatever language or software engineering aspect interests you
- Attend conferences
- Be an encapsulation and loose-coupling ninja.
- Orthogonality is key in creating maintainable, extensible software.
- Loose coupling must be burned into who you are as a programmer. The only constant in our industry is change.
- Dependency injection is your friend.
- Don’t make anything public unless it needs to be.
- Don’t use exceptions except in exceptional cases.
- Project estimation is hard. Don’t make a mess just to meet a monolithic schedule. Develop incrementally and iteratively. Don’t accumulate technical debt by kidding yourself that you’ll clean things up later. Measure twice, cut once.
- Embrace the agile mindset. Do prototypes. Pseudo-code. White board your ideas. Develop a skeleton application and then iterate on it. Have an agile approach/methodology to your software development, so that you can react quickly and painlessly to change.
- 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. Readability of code is far more important than micro-optimizations for performance.
- DRY: Don’t repeat yourself. If you find commonalities or duplication in your code, refactor it into a method/module/whatever. Refactor, refactor refactor.
- Be explicit. You must write code with the future developer in mind. If the future developer will be confused by your code, refactor it so your intent is obvious. Code should be self-documenting. Code is for how, comments are for why. Program defensively. Name variables and types in an obvious manner. Don’t abbreviate or shorten variable names.
- Know the greats. Stand on the shoulders of giants. In order to become a great software engineer, you have to know what to shoot for. You can learn an incredible amount by looking into the big names in our industry. These are some names that you should be able talk conversationally about:
- Edsger Dijkstra
- Scott Hanselman
- Donald Knuth
- Jon Galloway
- Ward Cunningham
- Anders Hejlsberg
- Miguel de Icaza
- Robert C. Martin
- Joel Spolsky
- Jeff Atwood
- Jon Skeet
- Scott Guthrie
- Alan Turing
- Bjarne Stroustrup
- Grace Hopper
- Phil Haack
- C.A.R. Hoare
- Bill Joy
- Alan Kay
- Tim Berners-Lee
- George Boole
- Ada Lovelace
- Yukihiro Matsumoto
- Dennis Ritchie
- Richard Stallman
- Ken Thompson
- Linus Torvalds
- Larry Wall
- Bill Gates
- Paul Allen
- Larry Page
- Sergey Brin
- John Carmack
- Ken Silverman
- Steve Wozniak
- Michael Abrash
- Richard Garriott
- Erich Gamma
- Richard Helm
- Ralph Johnson
- John Vlissides
- Tim Sweeney
- Practice Test Driven Development. Write code with the goal of passing your unit tests; Don’t write tests later, because you’ll probably just write the tests so that they pass, and won’t uncover the bugs, one off errors, etc.
- 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.) Don’t build something into the system unless it helps solve the problem.
- Strong-typing is your friend. Any errors you can catch at compile time helps you offload your imperfection as a human being onto the computer. Solve all warnings generated by your compiler, not just the errors. Recognize when dynamic typing is valuable and when it isn’t.
- Favor convention over configuration. Nobody enjoys XML soup, especially when it’s unnecessary.
- Understand what the abstractions are doing for you, at a basic level. You don’t need to know all the nitty gritty details, but you at least should know enough so that you understand the benefits and trade-offs of using the abstraction.
There is of course far more that could be said, but I think that’s a pretty good list for starters.