Dave

Software professional with 25+ years in SaaS product development, coding, consulting, platform transformations, and data migrations.

Contact: hikingdave @ gmail.com

Experienced Coders Dislike Code

This may sound counter-intuitive if you are desiring to learn how to code, but code should never be your goal. 

Code is one possible tool used to solve problems. The goal is to create that solution, not to write code. To be honest, code is painful in the long run. Every line of code you write has the potential to have bugs. It is another line of code you have to maintain. And it is another line of code where you gave a specific instruction to a computer, that may not be the correct instruction as the end users of your solution grow and change over time.

Experienced coders are fully capable of writing unbelievable amounts of code, but spend far more energy trying not to. Even when we are writing code, we try to minimize it. We write functions that can be re-used in mutiple places. We try to empower our end users to configure their own options for how a system would work, and avoid writing code that gives them only one choice (which is usually referred to as hard-coding). We would much rather read data and have flexible code that responds to that data. We believe in common principles with catchy acronyms like DRY (Don't repeat yourself - write code once and re-use it), and KISS (Keep it simple, stupid - complex code tends to be over-engineered and difficult to maintain.)

Once you've been coding for a while, the tasks you are assigned often stop being directly about how to write code. You start to be given more abstract tasks, to come up with a solution for a problem. And even if you know that the answer will be software, because the problem is related to a software system, your first question should always be whether something already exists to solve the problem.

I'll use an example from Hacker News (new.ycombinator.com) - a couple weeks back, a newer coder was asking how the community would solve the problem of giving their family a blog-like application to share family events. They had written a solution from scratch, but it wasn't quite working so they wanted to know what other people would have done. And all these brilliant, clever coders who drive much of the software world today repeatedly gave the same answer - Wordpress, Wordpress, wordpress.... oh, and have you thought about using Wordpress?

Wordpress isn't perfect. Really, it is a well-written software package running via dated coding languages, that has been destroyed by not-well-written plugins and themes...  but they key is that it already exists. And while the functions and features of Wordpress are often problematic, it is easier, faster, and less code to modify and fix those problems that it would be to re-write an entire system from scratch. As an added bonus, Wordpress has been around for many years, with millions of users, so they have figured out the answers that work best for most people. And many solutions can be built without writing new code.

Even in the corporate world, the right answer is typically to look around at all existing systems, and figure out what already exists that gives you a head start to solving your problem. Maybe you can integrate with an existing system, maybe you can at least copy some existing work. Maybe you can find oepn source code online. Anything you can do to not start from scratch is better. 

But there is a limit to this concept. While you don't want to write un-necessary code, neither do you want to build the wrong answer just because it had less code. You should not compromise on the quality of your solutions just to minimize code. The key is to find the solution that is the right answer, with less code being the secondary concern. 

At this point, if you are learning to code, it would be a good time to ask how all this applies to someone whose problem to solve is that they don't yet know how to code. My answer would be to remain clear on your goal - to learn to code. It is not your goal to produce 100 variations of the same code, but to learn 100 different coding techniques. In some ways, you don't want to worry about the best way to solve a problem, you want to try a new way. Over time, you'll have solved 100 problems and on your 101st can use that experience to select the best solution going forward. 

I'd recommend keeping that in mind as you select what lessons and projects to work on. Ask yourself if you are expanding your knowledge, or just repeating what you already know. Remember the infamous line that "There is a difference between 10 years of experience, and 1 year of experience repeated 10 times."