Some of the chatter over on LinkedIn rubbed me up the wrong way, so I posted the following:
The true measure of a software developer is being able to deliver value in the simplest possible way.
It isn't knowing the latest languages, frameworks, or techniques; it's knowing when not to use them.
It isn't delivering lots of sparkly new features; it's delivering the one feature that gives its users the leverage they need.
It isn't sitting behind a screen 16 hours a day; it's knowing who to talk to and building relationships.
It isn't being right; it's being an inspiration.
I thought it might be fun to dig into this a little.
… deliver value in the simplest possible way.
In the daily grind of producing code, it’s easy to forget that we’re not paid to program, or write tests, or stand in daily scrums; we’re paid to create something that helps someone else to something better. We’re paid to deliver value.
End users don’t care how many design patterns we used, or our test coverage ratio, or our velocity. They care that it works, that it was delivered in a reasonable time, and that, if necessary, it can be changed.
Which means it’s our job to discover where the value is, and to produce that value using simple code. That’s a skill founded in experience and confidence, and it’s not something AIs can currently do.
… knowing when not to use (languages, frameworks, and techniques)
If we are going to create simple solutions, we need to think hard about every technology we use: is it carrying it’s load? Sure, it’s fun and educational to try a new language, but is it necessary to do it on production code? We all love a good framework or library, but are they strictly necessary? Every external piece of code in a project adds dependencies and complexities, and each adds to the vulnerabilities of the app. Typical JavaScript projects now have thousands of dependencies, and each of those acts as a little anchor, holding you back when you want to change stuff.
…deliver the one feature that gives its users the leverage they need
Let’s face it: features are fun. All those little bells and whistles we add to our code are our way of showing off a little, of showing our mastery. But that’s not what our customers notice (or want). These people likely use your applications a lot: they know how to drive them and what to expect. They don’t need flair and features: these just get in their way. Look at some of the most popular systems on the Web. Wordpress admin screens look like they were designed by the same people who did Craigslist and Hacker News; in your face 1990s HTML. Doesn’t stop them being popular, does it?
…building relationships
Programming has never been about coding. That’s a good thing, because code is becoming a commodity. No, a good developer is an intermediary between the messy, poorly specified real world and the tightly constrained and unforgiving world of machines. The defining characteristic of a good developer is that they are comfortable in both of these worlds, and they know how concepts translate between them.
More and more, that role depends on interacting with people: customers, managers, other developers. Building relationships not only helps you do your job better; it most likely will help you find your next job.
It isn't being right; it's being an inspiration
In the end, no one cares if you’re right or wrong. They care about how you make them feel. They don’t need to be told what to do; thy need to see you doing it, and to be inspired to try it, too.
Am I wrong? Please comment,