The best code is no code

Dear new developer,

It’s paradoxical, but sometimes the best thing you can do is not write code. Remember, the value you provide is to solve the problem you are faced with (the outcome), not to write code. Custom code has value, but comes with costs. It needs to be deployed, maintained and upgraded. It has bugs. It requires a developer to change. It also has opportunity cost. Writing custom code to accomplish task A means that you won’t have time to accomplish task B, which may be either more urgent, more important or both.

There are a couple of ways in which you might solve a business problem with out writing a lick of code.

  • Use a library or framework. For instance, I worked at a place where they had written their own database connection pool. Why? I never got a great answer, but it wasn’t clear to me that one of the open source solutions wouldn’t have worked. You need to have an awareness of such libraries to be able to propose this.
  • Use a third party SaaS tool. I’ve seen people run their own in house git repositories. There may be good reasons to do this (including security or privacy concerns). But Github is going to give you a far better experience and unless you have a big team, probably better security and privacy. You need to know what the problem, the solution and the cost are to make an effective suggestion.
  • De prioritize the work. I was at a meeting with a CEO and we were talking about continuing an effort to integrate a set of outside data sources. I asked why, and we discussed it a bit further. It became clear that the reason we were thinking about doing it was because of inertia. It became clear that there was no real business reason to do it, and we prioritized other work instead. A clear roadmap and the willingness to question requirements are helpful with this path.
  • Do it manually. I was working on a startup and we had the need to occasionally refund customers. I could have integrated with the payment provider and had this case be handled automatically, but it was much much easier to document the process and handle it manually. Refunds happened rarely enough that there was no value in automating them. Here it is helpful to know how often the problem arises, how long it takes to fix manually, and how often it will arise in the foreseeable future.

Now, sometimes you may not understand the larger context of your work. You may propose a solution that isn’t the right fit, and there’s certainly nothing wrong with writing custom code to solve a problem.

In cases where I’m not sure I have full understanding, I always preface my questions with “I am not sure I have the full picture, but I think we could solve the business problem using solution A or project B, rather than writing custom code.” If you are working directly with the client, they likely won’t care, as long as the problem is solved. If you are on a team, the engineer or project manager running your project should have a good understanding of alternatives and why custom code might be the right solution. Most folks will be happy to share that reasoning with you.

In short, it’s better to keep your eyes on solving the business problem and be aware that custom code isn’t always the right answer.

Dan

PS No, this isn’t an April Fools Day post 🙂

Learn to use Google, and use it well

Dear new developer,

Searching is is important to writing and understanding software. Less so for giving you a base of knowledge. For that, I’d seek out books, video classes or side projects, depending on how you learn. Googling well is tough if you don’t know what terms to use. (I’ll use google as a synonym for a generic search. I’ll address issues of other search engines below.) Once you have a firm base of knowledge and understand software jargon, you can stand on the shoulders of giants.

Tips for searching:

  • Google the exact error message (almost). When you get an error message like nginx_1 | 2019/01/06 20:42:22 [crit] 11#11: *1 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied), don’t just cut and paste it into the search box. Look at the error message, and see what is unique to your situation. For the error message above, text like the nginx instance name, nginx_1, and the date and time, 2019/01/06 20:42:22, are unique to my installation. Searching on them won’t be useful. But the message text starting with connect() looks like it will be far more common and will likely yield good results.
  • Read the results, whether forum post or documentation, carefully. I’ve been bitten by this more times than I care to remember. But it’s very easy, when you find a stack overflow, forum or other result that seems to apply, to just cut and paste the top answer as quickly as possible and get back to what you were doing before you started searching. This is the quick path, but the better choice is to read the entire page and make sure that they are addressing the same issue that you are trying to address. You also want to pick the best solution (which may not be the first one, especially if the page is old). Sometimes newer libraries or releases have different paths forward, and so you should try to map the software you are working in to the one that the page refers to. The other reason to scan the entire page is that it will give you a sense of the different solutions. The underlying goal of doing the search is to incorporate the knowledge into your understanding so that you won’t have to do this Google search in the future (you may have to search in your project or commit log, but that’s quicker than redoing a google search, especially months from now). Trying to understand all the solutions and what they are doing is a way to be a just in time learner. Mindlessly copying the solution isn’t.
  • Add links to what you find in your commits and your comments. Do this especially if the solution is complicated or esoteric. You should of course write a commit message that explains your intent, but adding in the link can give additional context.
  • Think about the terms you use in the query. This is where foundational knowledge comes in. For example, if you know that active record is an object relational mapping tool, or that ruby is a dynamic language where every class can change another (which is called “monkey patching”) then you can know how to google for things related to these concepts. If you want to change a specific active recrod behavior, you might google “how to monkypatch active record” which will get you far more focused results than “how do change the rails database system”. This ca be iterative. Pay attention to the terms used in posts you find, and use them in new queries.
  • Consider using an alternate search platform. I use duckduckgo.com as my default search engine. Frankly, it’s not as good as Google, but it gives answers I need in about 75% of the searches, and I can easily run the same search on Google if I need it. I am supporting an alternative search ecosystem that will be better for the internet in the long run.

A last point is important enough that I’m going to break it out. Google, and search engines in general, work well because there’s content out there produced by people. You can take part in producing that content, either by adding to stackoverflow (which can be as simple as just voting an answer up or down–after you’ve tried the solution out), writing a blog post or responding to that forum post. If you encounter an issue no one has ever seen before, write it up, like I did here. This participation in the wider internet is crucial for the continuing useful functioning of the internet. So, participate in some way and give back.

 

Using Google to solve problems lets you leverage the hive mind for your development work. Don’t just use it. Use it well.

Sincerely,

Dan

Avoid The Impossible Goal of Being a Know It All

This is a guest blog post from Rick Manelius. Enjoy.

Dear new developer,

Can you name all 50 US states? How about their capitals? Every city in the US? Every town? Could you list the GPS coordinates of every coffee shop?

Of course, you can’t, wouldn’t, and don’t. It would be absurd to spend the time and effort to memorize such a vast amount of information that you can Google within seconds. Yet developers often fall into the trap of over preparing and learning a myriad of facts and syntax trivia for a new programming language or framework before diving in and getting their hands dirty.

A personal example: When I landed my first contract as a web developer, I recommended Drupal for the client’s project. However, I was deathly afraid of not being able to address any questions that might come up. To satisfy my “need to know it all” before I put forth an initial proposal, I purchased have a dozen ebooks and read the more popular ones cover to cover several times. Meanwhile, I was only dabbling in writing code by following the tutorials.  Unfortunately, this was about as effective as trying to learn a foreign language without a practice partner. The information was forgotten almost as soon as I learned it.

I contrast this with how quickly my experience and skills grew when I started to give myself the permission to play, to test, to tinker, and to interact with the community through IRC and the issue queue. It was there that I would run into a blocker and use those eBooks as a useful resource because I had a specific purpose in mind. Moreover, when I couldn’t find my answer there or with Google, I could lean on others that were actively learning, growing, and sharing along their career trajectory.

Years later, I discovered this humbling infographic titled Becoming a Web Developer in 2017. I love this because it highlights the absurdity in trying to learn everything about everything in the web dev ecosystem. While all sites eventually roll up to HTML, CSS, and JavaScript, the number of underlying technologies used to support them is visually overwhelming.

68747470733a2f2f692e696d6775722e636f6d2f4d576b654d31382e706e67
A select infographic from The Web Developer Roadmap 2017

Each of the boxes represents a different subject matter. Each of these subject matters has additional, hidden complexity. Also, within that, there might be subsystems that maybe only a few core maintainers of that specific project would understand. Each box may take a day or a week to learn the basics, but perhaps months to years to master.

Trying to do that for every topic becomes an overwhelming investment of time for increasingly diminishing returns. It’s equivalent to learning the GPS coordinates of every coffee shop in the US.

To make matters worse, this infographic only represents the hard skills necessary to produce and maintain the software and its supporting infrastructure. It says nothing about the soft skills of how to participate and grow a high-performance team, how to make solid architectural choices, how open source governance works, how to handle change and release management, how to apply different project management methodologies, etc.

Before I overwhelm you any further…

…there is hope.

You don’t need to know it all. In fact, some of the most successful developers I’ve come to know are skilled searchers and askers. They may not know the information, but they know where it could be. They know how to parse documentation to find the salient details they need to accomplish the task at hand. They have a network of colleagues in other specializations that they can lean on for help. They are confident in asking even basic questions (gasp) in public, because while it may seem obvious for many, there is always at least 1 other person who has the same question.

Let’s look at the medical profession for inspiration. While they all go to school for 6-12 years to gain a base level proficiency, they can then either stick to general practice or hone in on a dizzying array of specialties. When we get sick, we start by going to our primary care doctor. Their goal is to identify and solve the problem there, or narrow down the answer space and refer you to a specialist. Unfortunately, even the specialists don’t always know what the issue is. This is why people sometimes need 2nd or 3rd opinions.

The good news is that in software we don’t need to go to a school for a decade to get started with experimentation or specialization. We are one tutorial and terminal prompt away from trying a new language or checking out a new library and testing it in a local sandbox where little to no damage can be done. There is so much power in this! And it’s also where it can be overwhelming given the 28 million public code repositories on GitHub alone.

Adopt a Hive Mind Approach

We live in a golden age of sharing and collaboration. Developers from all around the world ask and answer questions on Stack Overflow. They write tutorials and howtos on their blogs or Medium. In any given city, there may be anywhere from 1 to 20 tech Meetups a week. There are podcasts, Reddit channels, newsletter aggregators, and active conversations on Twitter.

By asking, discussing, and sharing openly in one or more of these venues, you are adopting a hive mind approach. You are both able to contribute to and receive ideas, perspectives, and solutions. It’s hard to overstate the importance of this strategy and mindset. In my experience, it’s many times more valuable than reading the 3rd or 4th ebook on a given subject (although these are often a useful reference). Beyond just discovering technical solutions, interactions with other developers often result in friendships that can last well beyond the burning framework question you had when you first met them.

So my advice (take it or leave it) is to abandon the lone wolf, know-it-all approach to software development. Instead, learn to contribute to and draw from the collective skills, talents, and experience from our fantastic community that is literally all around you IF you are willing to connect with them.

Final point. I stayed isolated for years until I broke into the Drupal community. Once I did, my career rapidly transformed. I wrote about that here.

So get out there! And good luck!

– Rick

Rick Manelius is an MIT engineer turned web developer turned startup CXO (operations, product, and technology). You can connect and learn more on his personal blog and his LinkedIn profile.

Tips from a recent bootcamp graduate

This is a guest blog post from Jesse Ling. Enjoy.

Dear new developer,

Be comfortable with being uncomfortable. You’ll never know all the things. And that’s ok.

Ask questions – at the right time. There’s a fine line between reaching out for help too early and too late. Struggling is imperative to growth, but reaching out for answers too soon significantly hinders it. You’ll better understand where that line lives over time.

“Stand on the shoulders of giants.” More than likely, your problem has already been solved. Don’t be afraid of trying other’s solutions if it makes sense for your implementation. But do take the time to fully understand why and how it works.

Be persistent. Programming is difficult and often times frustrating. Don’t give up. The feeling of figuring things out after a struggle is amazing.

Network. Talk to devs at, below, and above your skill level. Opportunities can present themselves in mysterious ways. Utilize your network to not only help yourself, but more importantly to help others.

Sincerely,

Jesse Ling

Jesse Ling is a motivated and relentless problem solver, and a recent Turing School graduate seeking web development opportunities.

Patterns for managing up

Dear new developer,

Design patterns are common ways to implement solutions that can be repurposed across different systems and domains. This post proposes patterns for handling organizational situations.

Some really good excerpts:

No matter how amazing you are at your job, you will sometimes get feedback about things you could be doing better. It can be difficult to hear, especially if you are someone who works really hard all the time. When it comes to negative feedback, it is important to reframe the conversation. Feedback isn’t a bad thing. It is a gift, and you should always adopt a growth mindset and see it as a chance to improve.

I have received negative feedback about how I managed (I was managing how I would want to be managed, not how the employee wanted to be managed). It was really good to hear because it let me improve, but I definitely had to hold down a “wait a minute, you don’t understand” thought. If I hadn’t, I would have both lost that opportunity to learn, and possibly many more. If you react negatively to feedback often enough, people will decide that it isn’t worth giving to you.

And this is a good one too, about how to handle a problem you created:

When problems occur, there is a natural instinct to hide or deny that the problem is a problem, or that it is even happening at all. We want to minimize the problems that are our responsibility because, after all, a big part of our job is to make sure problems don’t happen. When you are proactive about sharing and fixing a problem, however, it is actually an opportunity to show you are an asset to the bosses.

Going to a boss and saying “I screwed up” is terrifying, especially the first time you do it. But going to the boss and saying “I screwed up and this is how I am going to both fix it now and make sure it doesn’t happen in the future” is terrifying but empowering too. The other alternative is to just hope that you are never found out, which is a miserable way to work (who wants to hide things? what happens if the problem gets bigger?). If you screw up, take a deep breath, come up with a plan, and solve the issue.

The whole article is worth a read.

Sincerely,

Dan

The right way to ask a question to get an answer

Dear new developer,

I already covered the right way to ask questions, but this post was so good that I wanted to share it. (I found it on hackernews.) Mike Ash gives advice on how to get answers from the internet.

Tips like “explain everything up front”, “post your code” and “follow up after you get an answer” will make it more likely that when you post a question on a forum, you’ll get some kind of help. The whole thing is worth reading, but here’s an excerpt that really resonated for me:

Many conversations I see indicate a subtle, buried belief that the list or chat is some kind of answer machine, and the key to obtaining a good response is to hunt around until the precise required format for the question is found.

It’s not a game, you’re talking to real live people. Treat them just as you would treat people you’re talking to face-to-face, and you’ll get much better results.

I have been one of those newbies under pressure to get something done. I’ve seen comments on github that lead to statements like this. It’s easy to forget that the folks helping you are

a) people

b) not getting paid by you

No matter how obvious the bug seems, or how much it is impacting you, you have to treat people helping you kindly. (You should do that even if you are paying people, by the way. If your boss doesn’t respect you, find a new boss.) Anyone who has run a volunteer organization knows that respecting the volunteers is the first step to getting anything done. Every time you ask a question on an internet forum or mailing list, you are essentially tasking a set of volunteers. Treat them right.

Sincerely,

Dan

Use stackoverflow, and use it well

Dear new developer,

Stackoverflow (SO) is great for three different kinds of developers (and someone can be all three over time):

  • those who are looking for answers, usually via Google (searchers)
  • those who are looking to showcase knowledge, usually by answering questions (answerers), and
  • those who have a specific question to ask (askers)

Every developer can be a searcher (all you need is Google). But you can look for answers poorly or well. Do it well by reading all the answers, understanding the question that shows up in the search results, and voting up both questions and answers. The voting in particular is a low effort way to add value to the entire developer ecosystem (because you are providing value to other searches). I know it is easier to take the first answer and move on with whatever task you are trying to get done, but try to take a bit more time and help others.

But you should strive to be an answerer or an asker. See if you can answer questions or add comments to clarify them or point to other answers. If you have a question that isn’t answered on SO, take the time to build out a solid question. If you end up finding the answer to your question, self answer it to help other folks out.

It is true that SO is not the most welcoming community, but it’s the preeminent question and answer site and so worth having a presence on. Don’t forget, the smallest amount of help you provide to SO may resound for years. I only have ~3k reputation but have reached almost 950k people. And beyond helping others, it’s a great way to demonstrate competence without venturing too far out of your normal workflow.

Sincerely,

Dan Moore