This is a guest blog post from Don Abrams, lightly edited. Enjoy.
Dear new developer,
When starting out, the hard part is balancing two things:
Banging your head against the wall
Additionally, as a new developer you’ll likely be encountering something for the first time: a codebase that is really really large. Like large enough no one knows all of it. You’ll want to learn how to navigate the codebase ASAP. Every place is different. If you can checkout all the code and get the product running in less than a day, you’re at a world-class shop. If it’s more than a week, I’m sorry.
After you learn to navigate the code, my recommendation is then to learn and copy the patterns that other team members use. So your questions should mostly be “how did someone solve this before?” or “hey, have you seen anything like this before?” If you look at the code they referenced and still have questions, then bring it back up ASAP.
If someone offers to pair, DO IT! Tip on pairing as a junior: be the keyboard and basically have them tell you what to do. You’ll learn how they think about the codebase and learn to navigate it better. You’ll feel stupid when they tell you “just” to do something, but those are the things you need to know. (“just XXX” signals that XXX is complex thing that you’ll take for granted soon– documenting those will really help the next junior).
I also recommend reading a LOT of code.Then, as you get a better command of the codebase and team patterns (3-6 months), you can start asking questions like “why did someone solve this before this way?”
That’s when it gets fun.
Don Abrams has over 10 years of software development experience and recently moved to France.
Every company has its warts (aka issues, aka problems). I have never met anyone who worked for the perfect company.
So, go in with your eyes wide open and choose what warts your company has. You may be able to help fix some of them, but some will be permanent.
One wart to avoid: an indifferent team. One just punching the clock, trying to get through the day.
If a company is full of people who don’t care, then you’ll have trouble fixing any other issue. Customers will be an after thought. And work will drag. (Yes, places like this exist.)
That’s not to say that a place where people care will be unicorns and roses, but at least people will want to fix issues and serve customers well.
How can you tell from the outside if people don’t care? Ask questions like “how do you improve processes” or “what do customers love about what you do” or “what changes have you all struggled with over the past year” or “how do you keep up to speed on the newest technology”. If the answers to these indicate a lack of caring and empathy, then I’d shy away from that place of work. If you are already in it, make plans to leave.
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.
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.
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.
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 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.
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.
Jesse Ling is a motivated and relentless problem solver, and a recent Turing School graduate seeking web development opportunities.
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.