For the past decade I've been a "software developer". But what I really do is develop solutions, which often happen to involve writing some code, but sometimes it doesn't. This post is about advice I used to give to new hires that were fresh out of college or were summer interns.

Code Romance

I decided to write about this after reading "Why Don't We Learn from History?" by B. H. Liddel Hart (a great book), when I read the following passage (emphasis mine) about the Duke of Wellington, who had defeated Napolean:

"It was because he saw the value of peace that he became so unbeatable in war. For he kept the end in view, instead of falling in love with the means. Unlike Napolean, he was not infected by the romance of war, which generates illusions and self-deceptions. That was how Napolean had failed and Wellington prevailed."

We've all heard the phrase "If all you have is a hammer, everything looks like a nail." But carpenters don't romanticize about hammering. Software developers do romanticize about writing code though. We think writing lines of code shows that we did something. We've somewhat moved beyond counting lines of code as a way to measure productivity, but you shouldn't think in terms of code at all.

Software developers ultimately create solutions. That can mean fixing a bug, adding a feature, improving scalability, or many other things, but ultimately you are solving a problem. The merit of your solution has nothing to do with how hard it was for you to do. Usually it's the speed that you fixed it, the ability to maintain it, and other characteristics, which usually are the result of doing something in the simplest way possible, and the simplest solution may mean not writing code.

Always cheat

One of the pieces of advice I gave to new hires that worked for me was "Always cheat". You have to re-teach college hires so they can become effective. It's not so much that they were taught the wrong things (although perhaps I should discuss some corrections there too at some point), it's that they were taught to value the wrong things. I think we all realize that most memorization is no longer very valuable. But there are other values that need to be untaught too. For example:

• No one cares if you do original work. I don't want you to create a snowflake for me. I want a problem solved. When you're stuck, you should look at stackoverflow, and probably copy and paste the solution you find there. Caveats of course apply that you should review it, and be mindful of licenses, etc.
• No one cares how much effort you put in. If you found a library that does what you need, you probably should use it!
• No one cares if "you" do anything at all. In school, homeworks have to be your own work. You have to take the tests. In a job, things just need to be done. If that means you re-assign the task to someone else who does it faster and better than you could, then that might be ideal.
• Take costs into account. When you're in college, $10,000 seems like a fortune. As a business, depending on the problem being solved, it may make more sense to buy something for $10K than have you work on something. Early in your career, you probably won't be exposed to many decisions like this, but consider this where possible. Getting things done matters. Whether or not it took any effort matters less.

How to not write code

What would you do if needed to sort some data? The recent college grad thinks about using merge sort, and thinks about Big-O notation, but hopefully even they are aware that they should never write a sorting algorithm. Every language has a sort function in it's standard library.

But do you need to write any code at all? Depending on the situation, maybe you should just write a bash script and use the Linux sort command and not write any "real code" at all. Or maybe it's a one time thing, and it makes more sense to just copy/paste it in Excel.

In a lot of cases though, you should just use a database. A lot of data structure and algorithm related knowledge you learned in school is irrelevant if you just use a database, and let the database take care of that for you. Need a binary search tree so you can search through your data quickly? No you don't, just use a database and put an index on that value.

Writing glue

Being a software developer involves writing very few lines of code, and the code you do write is usually just to glue things together. I think the concept of "10x developers" is largely about just knowing what exists out there to use and how to use it.

The majority of web applications, behind the UI, are just tying together a database, queuing service, file storage, and a proxy (for caching, load-balancing, and maybe other functionality). Those are your basic tools. Get familiar with them. Specifically, I prefer PostgreSQL, rabbitmq, and nginx.

Conclusion

Always look for ways to cheat. The job of a software developer isn't to write code. It's to create solutions that create value. Don't fall in the love with the means (writing code). Focus on the end goal of having something that works.