Learning to Think Like A Developer
Last week I went through what working at Efeqdev is like. Now let’s look at the whole new approach to solving complex problems I’m learning here.
What happened this week? #
I’ve gone from Rookie to Novice in DB design, front-end technologies, and Ruby went from Novice to Novice+ as I’ve gotten exposed to the concepts of metaprogramming.
Monday was AJAX day. In the to-do list app, I added functionality so checking off a task, deleting a task, and creating lists/tasks all take place without refreshing the screen.
But I’ve learned something far more significant than any particular bit of code can explain, and that’s what I’m going to share with you.
Thinking like a Developer #
Making software, simplified, is this process: 1. Identify the problem you’re trying to solve 2. Break the problem into pieces you can feed into the computer 3. Implement
I only just realized, since my first line of code 10 months ago, step 2 has tripped me up almost every time. This is what I call “thinking like a developer,” and it means you understand the purpose of the software so well that implementation is obvious, and knowing what to work on next almost feels like an afterthought.
Step 2 comes before :each do
endore implementation. This ability is the difference between people who can deliver results, and people who can’t.
Where do I start? #
You need to understand the purpose of the software you’re creating. This means identifying the absolutely crucial “need-to-have” features in no uncertain terms and from the user’s perspective.
That sentence is a discouraging mouthful, but this process is actually quite simple.
Start with a user story.
Using a flexible medium (like a whiteboard or scratch paper), map out the series of screens required to do what they need. At this point, don’t even worry about the technical side of everything, just focus on the “wish it could work like this” flow of whatever you’re creating and focus on one discrete process absolutely necessary to the overall purpose of the software.
But here’s where the magic happens: do this again with another user story. Pick the low-hanging fruit, the terribly obvious processes that need to happen. But just like you’d refactor code, now’s the time to refactor your understanding of how you can solve their problem.
How Designing Software is like Sculpting Clay #
At this point in the process, you’re defining what the software you create is going to look like, and showing it to the user to determine that’s what they really want. This is just like sculpting a pot for somebody, and making sure they like the look before firing the clay into a shape you can’t change.
Each user story brings more and more form to what you will create, but without incurring the cost of having to change code that’s already written.
But like sculpting clay, you can jump in anywhere at any point to change anything. There’s no distinct steps to take, rather an amalgam of smaller actions which result in the whole.
Black-box the Information Management #
Once you’ve got an idea of the problem to be solved and how the software will be used, now is the time to identify all the discrete pieces of data you’ll need.
This is where the developer becomes the boss. In fact, not only should you be the boss but the user shouldn’t even offer much input here beyond any questions you have…nor should they care! This is what they’re hiring you for.
Putting Your Pot in the Fire #
Now that you have a series of discrete problems to solve, its time to make pragmatic decisions based off all the information you’ve already uncovered.
Choose your tools, determine the acceptable tradeoffs you can make, and get going.
Be careful, and tread diligently…
The idea of the “Rockstar Programmer” #
Since plunging into the programming world, the concept of the “Rockstar Programmer” has repeatedly been brought up. The thinking behind this idea is that there are certain programmers who are an order of magnitude above others in terms of efficiency, productivity and being able to deliver code in the latest and greatest technologies.
There are people who fit this description, but that’s due more to the nature of skill and experience than inborn genetic talent. I also think for aspiring programmers, this notion is attractive…yet initially harmful. That’s because it leads to picking up and setting down new technologies, creating needless code in the name of glitz and relying on personal agency to ultimately power code that’s written to be useful for other people.
Strive to be a cowboy, not a rockstar.
Cowboys are just as efficient and productive as rockstars, but with key differences: they don’t write needless or glitzy code, they select tools with great care and wield them adeptly focused on exactly the results they need to produce which are valuable for the end user – and nothing more. There is no fluff, just pure execution grounded by experience and attentiveness to user needs.
In this video: Cowboy vs Rockstar
Next week, I’ll go over how to intelligently choose what to learn and how to, as a new programmer, adeptly hone and sharpen your technical edge