According to the dictionary, a practice is a repeated or customary action or the usual way of doing something.
In this chapter, I’ll share some of the practices that help me be a better developer. Some may be surprising. Others may appear to be common sense. With repetition and time, each of these practices will make you a more effective software engineer.
Just like starting a new hobby or starting to exercise, take it easy. Don’t try to pick up all of these at once. Choose one that makes sense to you and, well, “practice” it. After you feel comfortable with that one, choose another.
Don’t just write code—solve problems
Dear new developer,
It needs to be deployed, maintained, and upgraded.
It has bugs.
Logic changes require a developer.
It has opportunity cost; accomplishing task A with code means that you might not have time to accomplish task B.
I aim to solve problems without code whenever possible. This is a mindset that I picked up at a job because there were too many problems and not enough developers. I started to look around at ways to let my nontechnical colleagues overcome their roadblocks and realized that using such tools gave me more leverage too.
Use a library or framework—I worked at a place where they had written their own database connection pool. Why? I never got an answer, but from what I saw, one of the open source solutions would have worked just as well. Be on the lookout for open source projects and tools that you can suggest when someone considers writing low-level solutions like that connection pool.
Use a third-party SaaS tool—I have seen companies run their own git repositories. Now, there may be good reasons to do this, such as security or privacy concerns. But GitHub has a better developer experience and likely a better security infrastructure. If you want to suggest one of these tools, make sure you understand the problem, available solutions, and ongoing costs.
Deprioritize the work—Once I met with my CEO to discuss integrating outside data sources to improve our product. I asked why we thought the additional effort was worthwhile. We were considering this work only because we’d done it in the past. In other words, inertia—not generally a good reason for a business decision. We prioritized other work instead. If you want to avoid useless or lower-value work, have a clear road map and a willingness to ask questions.
Do the work manually—I was working on a startup, and we occasionally refunded customers. I could have written custom code to automatically process these refunds. But it was much easier to document the process and refund customers manually. The refunds happened rarely enough that automation wasn’t worth it. If you are considering a manual process, understand how often the process will need to be done, the amount of effort involved, and if growth will change either.
Now, new developer, sometimes you may not understand the larger context of your work. You may propose a noncode solution that isn’t the right fit. Writing code can solve a problem quite elegantly and may be the best solution.
Whenever I’m not sure I fully understand a situation, I confess my ignorance before I make suggestions. I might say something like “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 our own code.” If you are working directly with a client, they won’t care, as long as the problem is solved. If you are on a team, the lead engineer or project manager should have a good understanding of alternatives and why custom code is the right solution. They should be happy to share that reasoning with you.
Practice solving business problems, rather than writing code.
Sincerely,
Dan
Look around corners
Dear new developer,
Just like chess players think many moves ahead, consider the ramifications of your choices. Thinking about consequences will help you make better decisions. Strive to plan out two, three, or more steps.
And don’t just plan for the happy, straightforward path to success. Practice looking around corners, thinking about what might go wrong.
I was chatting with an acquaintance about technology choices at his employer. He referred to the “original sin” of choosing a NoSQL database as their primary data store. This decision had ripple effects that lasted years, affecting features, teams, and timelines. This early choice constrained future options for dozens of developers. You may not be making the kind of choice that influences teams for years, but your technical decisions also constrain options.
The biggest decisions are platform choices, such as Rails or Django, Java or Golang, MySQL or PostgreSQL. But even smaller choices have ripple effects. I can’t count the number of times I’ve said to myself “Oh, I’ll just upgrade this one thing; it won’t be hard.” That component upgrade cascades, requiring other changes. When I recognize this, I can abort, commit, or pause and discuss. But in all these cases, I would have been better off considering the possible scenarios before starting.
Think through the ramifications—practice imagining what might go right and what might go wrong. For example, someone might say “we want to allow people to change their email address.” Okay. What if a user’s email address is the primary key of a table? What if the email address connects user data across accounts? This change may be more difficult than you thought.
I’m not saying don’t change. That way lies madness—and COBOL. I’m also not saying you should overengineer and write code for every eventuality. YAGNI1 is a common expression among developers for a reason.
Rather, consider how simple changes in complicated systems often ripple out and cause unexpected havoc. Planning how to test, mitigate, or handle this is a good way to avoid unpleasant surprises.
You can’t know what lies around every corner. But that doesn’t mean you should pretend there are no corners.
Sincerely,
Dan
Read code
Dear new developer,
Coding is fun. You take an idea , breathe life into it, and have a finished product that people can interact with. Software development is an amazing occupation, and you can build tools that change the world.
Companies pay for code—Code is expensive. Companies don’t like to spend more money than they must. They want to amortize the expense of code across as many years as they can. This means you often change existing code rather than write new code.
Bugs happen—The software is almost correct, but not quite. Anyone fixing a bug must understand the existing code and how it works.
Business requirements change—Code that supports the business needs to change as well. But before that, the developer modifying the code must understand how it currently works. New features should also integrate with existing structures.
Over the years the business commits to a codebase, there will be many changes and bug fixes.
There is the rare piece of software that is “set and forget.” It hums along quietly with no changes. I was responsible for such a system; it ran for five years with zero changes as it sent email alerts about new houses for sale. Different industries have different software longevity. But even in government, where systems live for decades, code still changes.
As a new developer, you will mostly likely spend more time trying to understand existing code, to debug or change it, than writing new code. Of course, this ratio depends on what your company needs. A startup with a great idea and nothing else will require a greater portion of time spent writing software than an established business. But even in a startup, once you acquire users, you begin the maintenance phase where bug fixes and reading code take a greater and greater share of your time.
- I scan—I’m seeking a high-level overview. This information should be written down, but sometimes needs to be extracted from someone’s brain or from the code. In the latter cases, document what you learn. I’m trying to answer the following questions:
What problem does this code try to solve?
What language and/or framework is it using?
Is it written idiomatically?
What are the main components of the application?
How do they fit together?
I dive down—I focus on the problem at hand and try to identify where changes should be made. This usually involves opening source files and moving between them, trying to understand the logic of this subsystem. I also look for patterns in the code, including different levels of abstraction, homegrown libraries or frameworks, and coding idioms. Consistency matters so I want to learn the style of the codebase.
I use the scientific method—I write a hypothesis in a text file or notebook, make small changes, and see what happens. All the better if you can make changes in a staging system or in a development environment. Automated tests are helpful in verifying my theories and in making sure I don’t inadvertently change something else. If you can’t make a local copy of the entire application, you can still run chunks of code locally to get a better understanding of what the system is doing.
How encapsulated the component or system is. Will changes there ripple out? Or are there clear boundaries?
Is the code you’re changing well tested? Or untested?
How critical is this area of the codebase and the larger system? The more important, the more you’ll want to understand it before modifying it.
Discuss these questions with your team. But realize an understanding of the entire system only comes with time.
Also, ignore any desire to throw away old code and rewrite it, especially if you don’t understand it. Old code is reified knowledge, and you discard it at your peril. There is a time to junk old systems. When you don’t understand what they do is not it.
Software systems spend most of their life running in production. Change happens, but that requires understanding what is already present. This means reading code is more important than writing code .
Sincerely,
Dan
Estimate your work
Dear new developer,
Knowing how long it will take to build software is almost as important as being able to build it. Web page, component, entire software subsystem, it doesn’t matter—as soon as your organization decides to build it, a pressing question will be “how long will it take?” This process is known as estimation. It’s difficult but you can get better with practice.
Estimation is important for three reasons. The first is opportunity cost. Each feature built necessarily excludes creating a different one. Both the costs and benefits of each effort must be evaluated and prioritized to build those of the highest value first. The length of time it takes to build software is a key component of its cost.
Another reason is scheduling. Very often software teams need to deliver based on external deadlines. These can be hard, fixed deadlines, such as the date of a trade show or a customer commitment, or softer, such as an internal road map commitment or a promise to another team. Delivering on time lets other parties execute their own plans. Software isn’t built in a vacuum.
In preparing for battle I have always found that plans are useless, but planning is indispensable.
The value of estimates is not only prioritization and scheduling—these often shift over time. Stuff happens, estimates get pushed, priorities reworked.
The third reason to estimate is that the team is forced to plan. This leads to discussions and questions about requirements and implementation details. Such planning forces you to think concretely about what you are building and the trade-offs you will have to make. These discussions inform and change the software. Changes at this time should be welcomed, as they are far easier to make before any code has been written.
I have tried to define requirements for a system and build it at the same time. This ended up costing more money and taking more time than if we had done a detailed estimation session. If a client needs to see a solution before they “get” it and can have a discussion about the requirements, use lightweight prototyping tools to avoid writing software.
New developer, there are many ways to estimate. Following team practices ensures consistency.
Wrote a task list for the project. Everything I could possibly imagine needing to deliver the final product would go on the list: requirements definition, research, development, testing, deployment, even a ballpark guess on bug fixing. I wanted to be as thorough as possible.
Put the list in a spreadsheet with four columns, as seen in Table 5-1.
- Add a high and low estimate to each task. Specify both in ideal hours; six ideal hours per day was my rule of thumb.
The low estimate was how long the task would take if it went perfectly—no questions, no changes, no unpleasant surprises, just understanding the task and executing.
The high estimate was how long the task would take if things went sideways—if, for example, I ran into an obstacle and had to rebuild an entire component.
If you are on a team, you may want to use days or half days rather than hours, but I wouldn’t use larger units than that. I don’t know anyone who can reliably estimate software tasks in units of weeks. It simply isn’t granular enough. If this is a large project, estimates will get rolled up into weeks or months—just don’t use those units of time for task estimation.
Add any questions uncovered or assumptions made during the task time estimate to the notes column. Questions must be answered and assumptions verified before the estimate is complete. I also used the notes column for any uncovered solutions, helpful libraries, or research findings.
To arrive at an estimate, I averaged the low and high task estimates, then added 20% as a “fudge factor” for everything I forgot.
If I wanted the number of calendar days, useful for committing to a ship date, I divided the total hours estimated by the ideal hours per day.
Task estimation
Task | Low Estimate | High Estimate | Notes, Questions |
|---|---|---|---|
Build out the login page | 4 | 8 | Use devise gem |
There are many other estimation techniques out there. My method is based on personal experience rather than research. It is lightweight but ignores individual variation and team dynamics. If you want to learn estimation in depth, I’d recommend Software Estimation: Demystifying the Black Art by Steve McConnell. The Agile methodology has its own way of tracking the future speed of software development as well.
Getting feedback on how your estimates track with reality improves the process. While you get coarse feedback on the accuracy of your estimates when you hit or miss your ship dates, tracking task time helps you see what sections of your estimate are incorrect. This is tedious, however. Tracking forgotten yet required tasks is also helpful. If you or your team omitted a required activity from the project task list, think about how to make sure that doesn’t happen in the future.
If a project is big, break estimates into milestones. This allows for more frequent check-ins and reports. These are helpful for letting a client or other teams understand progress. If a task takes longer than you think, you may need to course correct. This typically involves sacrificing scope or pushing a delivery date.
When a task is taking longer than you estimated, you must tell people who are depending on the completion of that task. If you have thought of a way to deliver the functionality on time using a different solution, share that. But even if you haven’t, what everyone wants to avoid is a nasty surprise toward the end of a project. No one likes that.
There are some situations which don’t require estimation. Part of the joy of a side project is that you can explore new technologies and techniques without commiting to a timeline. Unless, that is, you are trying to work on your planning skills, in which case, estimate away. Work you do for free, such as open source work, also requires less planning and estimation. However, if you have users of your software, they’ll welcome a road map.
Others rely on your work. Estimating delivery allows them to plan.
Sincerely,
Dan
Debug systems
Dear new developer,
Make the problem as simple as possible. Start with the reported issue. Keep isolating and removing pieces to see if the problem persists. Modern systems are complex, and the less you must think about, the better.
Begin with a hypothesis and work to prove it, refining it as you know more information. Sometimes I find it helpful to write the hypothesis down as that in itself can expose areas for investigation.
Determine the desired end state. Fixing the root of the problem is usually the best course of action. There may be times when that is too costly, and fixing the symptoms or providing a workaround is what is needed.
Pay attention if anything seems amiss or strange, no matter how small. These are clues.
Keep notes about what you've tried. Put them in a chat system if the debugging is high priority or if you want to collaborate with others, say on fixing a production system during an outage. Or take notes in a local text file if it is a bug you’re trying to understand in your local environment.
If the bug is new, examine recent changes to the system. These are not always the cause, but often are part of the problem. Rarely does a system degrade spontaneously.
Write an automated test which shows the faulty behavior. This will speed up your fix because it gives you a tight loop of “run test, make change, run test, make change.” Having a test ensures your changes fix the bug. Adding this test to a suite will prevent this bug from popping up again.
Follow the flow of data. Start at user input or data storage when isolating the issue. See where it first appears. For example, in a three-tier web application, start with either the browser or the relational database.
Minimize impact to users. If you are working on a production bug, ideally you can test on staging. This gives you the most flexibility. If you must debug on production, limit debugging statements to certain users or in hidden comments.
Make sure that where you are testing mirrors as closely as possible the system where the bug appears. Otherwise, you will spend time chasing environment differences—data or traffic are especially difficult to replicate.
Let’s get a bit more concrete . One time I helped a friend debug a system for his client. The client was seeing doubled orders on his ecommerce site. That is, someone would order five widgets on the site, but the system recorded two orders, resulting in ten widgets shipped. It didn’t happen with every order placed. There was no discernible pattern. There were no recent changes to the code of the ordering subsystem—it was a PHP application, and I was able to verify that by looking at file timestamps.
No one was happy. The customers weren’t happy about being charged twice. The client wasn’t happy about shipping product twice. My friend wasn’t happy because his client was unhappy. He had examined the system and didn’t have any luck finding the issue.
I had never worked with this ecommerce package before nor any like it. There was no staging environment. I was debugging in the dark. I didn’t even have a way to submit test orders—any order I put in would result in my credit card being charged.
What I had was database and server access. I also had a list of the customers who had been double charged. My hypothesis was that something in the code was causing this behavior only for these specific customers, so I set out to find out what they had in common.
After a brief look at the PHP code, I realized that understanding the codebase would take a long time. So I started by looking at the web server log files with grep, vi, and all the other great Unix tools, seeking anything amiss. I noticed something weird. The logs showed the server was restarted often: every 15 minutes. After further investigation, the restart times lined up with the double charges.
I looked at the cron settings and found that someone had added a line that restarted the web server regularly. I asked my friend and the client if they knew why; no one did. I disabled the cron job that restarted the server. We watched for a week to see if the double orders continued.
They did not. Success!
For this client, fixing the symptom was enough due to a planned move to another ecommerce package. I didn’t need to dive in and try to fix the root cause.
Debugging modern systems means working across many pieces of software, some of which you may be unfamiliar with. Being able to hypothesize, test small changes, and notice things that don’t seem quite right are all parts of successful debugging.
Sincerely,
Dan
Assume positive intent
Rick Manelius is an MIT engineer turned web developer turned startup CXO (operations, product, and technology). You can connect and learn more at https://rickmanelius.com/LND.
Dear new developer,
Chris could have become my worst nightmare. He was a key stakeholder and decision maker on the largest active account that my company was dependent upon for its financial stability. That wasn’t the problem. The issue was that we were midway through the initial project deliverables and it was becoming apparent to team members on both sides that the budget specified on the contract was insufficient to deliver a solution that would actually meet the needs of their business. This was a huge problem. I was doing my best to navigate the situation and keep calm on the outside, but on the inside, I was stressed to the max knowing that it was possible that we could lose the account and suffer a significant financial loss.
As time went on, tensions continued to rise. Additional meetings were scheduled to discuss budgets and contracts. People started to become irritable, dig in their heels, and act in ways that were clear signs of CYA (cover your ass) in progress.
Chris could have crushed me, and yet he didn’t. In fact, he did the exact opposite and taught me an incredibly valuable lesson. Amid the bickering on one phone call, he asked his colleagues to stop this behavior and to assume positive intent instead. He went on to describe how this is a philosophy he’d adopted in his personal and professional life as a means of being more efficient, effective, and solution focused. After all, approaching any situation with the opposite mindset results in wasted time and energy. Assuming negative intent means you’re spending lots of time second-guessing everyone’s motivations, being combative instead of collaborative, and slowing everything down by having to update contracts meticulously instead of going off of a handshake.
What about when…?
It’s 100% reasonable to have a high degree of skepticism within a low-trust environment. For example, I would never assume positive intent and allow my daughter to be alone with a registered sex offender just because the person claimed they had changed. I would also never trust an alcoholic with a house full of liquor. Once a person has violated trust against a particular metric, it's okay to take a different position in order not to put yourself in harm's way.
This advice is not without risk. Some people will leverage this against you. There are con artists and sociopaths out there. Martha Stout claims 4% of the population falls into this category. In short, if you start from a place of positive intent, you are going to get screwed over by at least 1 out of every 25 people you encounter because they literally have no moral compass. However, in my experience, the rewards outweigh the risks. To invert the statistic by Martha, 24 out of 25 people can feel legitimately bad if they know they’ve caused harm to someone else. Essentially, the vast majority of the population has a conscience that acts as the moral compass to steer them from intentionally causing harm to others. It doesn’t always work, but it’s better than nothing. And given that 96% of people fall into this category, I feel there is a greater risk in approaching those relationships from a place of distrust .
The ROI of trust
There is an entire book called The Speed of Trust that provides qualitative and quantitative evidence that high trust situations result in massive gains in efficiency and effectiveness in relationships. We know this intuitively. If we are skeptical of an expensive new product or service, we might spend hours of time researching to make sure we’re making the right decision. However, if we get a recommendation from someone we trust, that may be all we need to decide in an instant.
So if trust is so valuable, how can we get there more quickly? Well, there are two different ways. We can start from a place of skepticism until someone has proven themselves worthy to be trusted. Or we can start from a place of positive intent right from the beginning and keep it there until they violate that trust. Both are feasible, but only by extending trust first will most relationships ever get to the place where you can experience the gains outlined in Stephen M. R. Covey’s book.
Just remember there are caveats. It’s all a matter of whether you’re willing to accept the risks!
—Rick
Express gratitude
Dear new developer,
Being grateful makes me happier . It works for others too—two researchers from the University of California found that when they asked people to write about what they were grateful for, after ten weeks, they felt better about their lives.2
Engineers are usually treated well.
It is lucrative.
There is a relatively low barrier to entry.
Challenges are varied.
It is a broad industry with many different domains to work in.
Many jobs allow autonomy.
Remote work is a possibility.
Continuous learning is welcomed.
Developers are in high demand.
When I think about these benefits, it makes the frustrations easier to bear.
It’s also important to express gratitude toward others. Every project is a group effort. Thanking team members builds rapport and makes any future difficult conversations easier.
Be professional. Make it short and sweet.
Be specific: “thanks for pairing with me and debugging the XYZ component yesterday” is better than “thanks for your help.”
Spread it around. Include your peers and people from other departments.
Being grateful makes me a better teammate. Who would you rather work with? A sullen, unhappy, grumpy coworker or one who regularly shows appreciation?
Sincerely,
Dan
Cultivate the skill of undivided attention
Josh Thompson looks forward to being a senior developer someday. He’s only a few years into his career in the software development industry but enjoys getting to bring knowledge and skills from his prior careers into his current role. He lives in (and works remotely from) Golden, CO, with his wife and loves to rock climb and read books and can often be spotted in Denver area climbing gyms or local crags.
Dear new developer,
You know that there’s a chasm between your skill level and that of the mythical “senior software developer.”
If you build a list of topics you encounter on your job that, if learned to a deep enough level, would put you on the same level as a senior developer, you’ll end up even more demoralized than before compiling that list.
No need to assemble this list yourself! I’ve done it for you.
Breaking complex unknowns into simpler unknowns that can be further split into individual tickets
Adding tests to complex, legacy code to guide further refactoring of said code
Using grep to comb through server logs to diagnose a hard-to-identify-and-reproduce problem
Provisioning new servers
Building bash scripts to automate complex workflows
Digging into gem source code to shed gem dependencies while maintaining certain features
Understanding indexing well enough to see that certain queries that we thought were using indexes were not and fix this oversight on the fly, without causing any blips in availability
Each of these line items has many books written about the topic.
It seems like you could fill a bookshelf with books that address knowledge senior developers have available to them inside their own heads.
It takes me long enough to work through a single book, so imagining a bookshelf of extracurricular reading is quite daunting.
It might feel daunting for you, too.
Leading vs. lagging indicators
The preceding list of skills is a lagging indicator of the underlying knowledge. We should not target improving lagging indicators, we should improve leading indicators.
Josh, what is this “lagging and leading indicator” stuff?
Great question!
A lagging indicator is “evidence that something has already happened.”
If you got an A on a test, that is evidence that you learned the material.
A leading indicator is “evidence that something will likely happen.”
If you want to get an A on a test, you should study in a similar way as others who have gotten an A on that test. Maybe you need ten high-quality hours of study to get an A, so “number of high-quality study hours” would be a leading indicator of your grade.
We no longer take tests (phew, I hated taking tests), but we get mini-tests of our knowledge, daily. We’re paid to solve problems, which often require learning new things.
Rather than focusing on a list of things other developers have learned, and targeting that list, I humbly propose that a leading indicator of acquiring this kind of knowledge is “hours per week spent in a state of intentional deep work.”
The preceding list of topics is a lagging indicator of a high degree of technical knowledge. Someone acquires the knowledge, and then, and only then, can demonstrate that they have it.
Leading indicators are “predictive,” in that if you can identify correctly those indicators, you can predict the outcome of the issue at hand.
In this case, the issue at hand is “become significantly more experienced in the domain of software development.”
I propose that a leading indicator of someone gaining these skills is the amount of time they spend in a state of deep work.
I’d encourage you to read Deep Work: Rules for Focused Success in a Distracted World by Cal Newport. The author makes a case for deep work being a key role in the success of “knowledge workers” (which includes many types of work, including, of course, software development).
In order to produce the absolute best stuff you’re capable of, you need to commit to deep work.
The ability to quickly master hard things and the ability to produce at an elite level, in terms of both quality and speed, are two core abilities for thriving in today’s economy.
“To learn hard things quickly, you must focus intensely without distraction.”
“Your work is craft, and if you hone your ability and apply it with respect and care, then like the skilled wheelwright you can generate meaning in the daily efforts of your professional life.”
“The key to developing a deep work habit is to move beyond good intentions and add routines and rituals to your working life designed to minimize the amount of your limited willpower necessary to transition into and maintain a state of unbroken concentration.”
Imagine two equally knowledgeable early-career software developers. They have the exact same skills on January 1. If the first software developer spends 4 hours a week doing deep work, while the second software developer spends 15 hours a week doing deep work, their trajectories will be quite different, and that second developer will quickly gain technical knowledge and proficiencies.
So, if you’re an early-career software developer, track the time you spend doing deep work. That has you focusing on a leading indicator of growing in your skills.
What is measured, improves.
You’ll track how many hours you spend doing deep work, and by tracking it, you’ll do more and more of it.
In conclusion
Do more deep work , and over a year or two years, your skills will grow much faster than those doing less deep work. Eventually, you might find that you’re doing the work of a senior developer!
Good luck!
—Josh
Build empathy
Dear new developer,
You’re probably frustrated and confused. You’re learning a lot and you don’t understand everything. Sometimes concepts click and it all makes sense, and other times you’re confused and staring at a brick wall. Perhaps you just want to make things work. But they don’t.
Good.
I say that not because I’m a sadist or dislike you. I imagine you’re a pretty nice person! I say that because I hope you’ll remember the frustration you are experiencing. It will make you a better developer.
Why?
Because that confusion, that frustration, that dissatisfaction—it is what many users of software applications feel all the time. I’ve watched family members try to do tasks I’d consider simple and have seen this firsthand. People are trying to use software to help complete a task and get on with their life. The program is just a tool.
They don’t care about the elegance of your code.
They don’t care how much you love to develop.
They don’t care if you are learning and growing.
They want to finish their job, complete their task, and check that box.
And, honestly, the tools we software developers provide are frustrating. They’re buggy. They’re slow. The fact that anyone from 1980 would be amazed that there’s a free authoritative online encyclopedia providing answers to almost any factual question from your phone or that shopping from the couch is normal is beside the point. People are still banging their heads against the limitations and flaws of the software we provide.
I don’t write this to cause you despair, new developer. Progress happens, but it happens one person at a time. Every software engineer must act with empathy toward their frustrated users. Talk to them. Understand them. Care about them.
If you remember the frustration you are currently feeling as you struggle to learn new technology and check your own boxes, you’ll have more empathy for your users, just trying to use your product to get something done.
Sincerely,
Dan
Don’t complain about the code
Dear new developer,
There will come a time when you are examining a software system and trying to understand the choices behind it. You may be looking at a class, a subsystem, or something larger, like an application’s architecture.
I remember looking at a system which generated custom quotes for an industrial tool. I was modifying the software. Someone mentioned that they rebooted the server every night because of a memory leak which otherwise would bring the system down. “How janky” I thought to myself. Later I found that the team had spent significant resources debugging this problem and simply couldn’t find the solution. The restart dealt with the symptoms and was the least bad option.
I promise you, at some point in your career, you’ll wonder what the hell the original programmer was thinking. You’ll wonder why this system is still in production. You’ll wonder why someone didn’t fix this. You will be tempted to trash talk this piece of software to your colleagues.
It’s not helpful—It’s perfectly acceptable to point out issues and ask questions about why choices were made. It’s a good idea to suggest improvements, whether software changes, code removal, or library upgrades. But complaining about the existing system doesn’t do any of that.
It displays a lack of empathy—Chances are you don’t know the constraints and pressures the original developer and past maintainers faced. Making judgments based on the end result without understanding the process is like hiring someone based on the color of their shirt—sure, you know something, but you certainly don’t have all the information.
Trust me, new developer, in the future you’ll face constraints too. Constraints like ignorance, short deadlines, or small budgets. You will make suboptimal choices. At least once in my career I’ve come across a boneheaded piece of code. Cursing under my breath, I wondered “who wrote this crap?” As I pulled up the commit log, my face fell as I realized that I had. Doh!
What should you do if the system doesn’t work at all? In that case, understanding how this system was built is even more important—you want to prevent those issues from recurring. But again, complaining doesn’t help understanding.
Sincerely,
Dan
Avoid jargon
Dear new developer,
One thing I’ve learned is that if you can’t explain a technology choice in a way that a nonengineer can understand, you don’t get it either.
It is easy to use jargon to blur your lack of understanding. Now, jargon in and of itself is not a bad thing. It’s shorthand for complicated concepts. If I say “RDBMS” to another experienced developer, they’ll know I refer to a piece of software which provides safe, durable, transactional data storage. See how jargon builds on itself? The word “transactional” is jargon as well.
But just as if on a car trip you take one shortcut after another, you’re likely to get lost, similarly too much jargon can blind you, or at least put you in a fog.
Don’t take the jargon shortcut until you have done the full drive and truly understand what you’re referring to. Practice describing what you do in a way that is understandable to a layperson. An example description of an application I’ve worked on is “we pull real estate information from different sources and publish it.” I confess, I had to rewrite that sentence a few times because I started out with jargon.
Does this mean you need to understand everything from CSS to the voltage of your power supply before you can be effective? No. What it means is that you should be careful when you are using words that you may not fully fathom. A great way to better understand them is to break them down into terms a nontechnical user might use.
Clarity for yourself
The ability to teach others
Influence in your organization
What’s not to like?
Sincerely,
Dan
Realize time is money
Dear new developer,
Don’t be penny-wise, pound-foolish. Your time is worth a lot. Spend money to achieve your goals.
I heard a client say once that their time was essentially free—they were helping rework a system and were interested in paying us, their development team, as little as possible. I understood the sentiment. As a developer, I’ve been overly cash conscious myself—some might even call me cheap.
However, buying services provided by someone else essentially gives you more time. Who wouldn’t want another couple of hours a day?
Buying a book or video course instead of reading free documentation—One time, for a consulting gig, I needed to integrate with Stripe, a payment processor. I found a $30 technical ebook that illustrated, with code, the exact integration needed: taking a credit card payment from a Ruby on Rails web application. The free alternative would have been a couple of hours reading the docs and experimenting. The time I saved was worth far more than $30.
Buying and using tools—I have colleagues who use commercial IDEs like JetBrains. Buying and mastering this IDE increased their software development speed.
Paying for support—If your business relies on other software services, pay for support. Depending on the provider and the plan, you may receive answers to your questions more quickly or have access to experts. AWS, a cloud provider, has a support plan which gets you direct access to experienced architects. Don’t hesitate to access this support, either. I had a colleague who saw corrupted images in a web application. He spent a lot of time looking at our code, but the issue was caused by the service provider. We only found that out by opening a ticket with them.
Buy commercial software—Pay for a solution which meets your needs. I always ask: “is this core to the business” and “what would happen if this paid service went away” when considering options. If it is not core or is easily replaceable with another provider, buy it. You can spend a lot of time and energy splicing together “free” solutions, to say nothing of maintaining them.
Paying for consulting or training—A day with a consultant can save you weeks or months of time. You are paying for their experience as well as the knowledge of their mistakes so you can avoid them.
Not all of these necessarily apply to you right now, new developer. You may have no budget to spend at work. But you can still trade money for time when it comes to learning. Get that subscription to Udemy or Safari. Buy that book. Explore that commercial tool.
Your time is precious. Don’t waste it; spend money.
Sincerely,
Dan
Say no
Dear new developer,
There’s an art to saying no. And there’s power in doing so.
I once worked on a project creating a Yahoo clone. The lead developer fell ill and the team needed someone to step up. I said “yes, I can help.” I jumped in and led the project to success. I ended up working 96 hours one week. The site launched. My company expressed their gratitude with a gift: a t-shirt and six-pack of beer.
I have learned since then how to say no.
“Yes, I’m happy to shift to working on task B, but should I finish task A first?”
“Yes, I can help you with the release, but Jane is waiting on this feature. Should I let her know?”
“Yes, I’d love to work on that project, but shouldn’t I finish up this component first?”
Using this turn of phrase makes it clear that you are happy to help but are aware of your other obligations. Practice this with smaller requests first. Always ask for prioritization. Especially as a new developer, you often don’t have the bigger picture. Maybe task B is blocking three other developers from making forward progress. Maybe that release is more important because it includes a high-priority bug fix. Maybe that component can be put on hold for now.
I have never once been dinged when I asked for prioritization. It shows that you want to work on important things, have an awareness of the bigger picture, and are flexible and helpful. Just a warning—you will be asked to estimate task completion time as soon as you ask for prioritization.
The power of saying no is that it protects your time. You only have one life to live. When you have a salaried job, there’s not much downside for your company to take more of your time. Even if your boss is nice, you are responsible for establishing and protecting your boundaries. If you say “yes” all the time, you will end up working a lot of extra hours. Other aspects of your life will suffer as a result.
I enjoy working. When I was starting out, I was proud when I stayed late: “look, I’m getting stuff done” and “I’m building cool software that helps people.” But the point of life is to live, not just to work. As I look back over my career, I’m proud of what I and others have built. However, a lot of that software is no more. Will I ever get any of that 96-hour work week back?
Make it clear that you’re happy to help, but don’t let work suck you in. Say no.
Sincerely,
Dan
Play a lot more
During the day, Zach Turner is a software engineer at Culture Foundry, a full-service digital agency. At night he is a maker of things useful, useless, and everywhere in between.
Dear new developer,
Don’t forget to play . I spent the year after undergraduate working and learning. My goal was to find a job at a company, and eventually I succeeded. However, my passion dwindled because it was always put second to finding a salaried position. As a result, my desire to play with and learn about new technologies simply because they are interesting has dwindled, and my enjoyment of my job has suffered.
Allow yourself to approach the world as a kid again. Buy an electronics kit and only do the first example experiment. Learn Hello World in 30 different languages. Start a passion project without worrying about finishing it. If you do finish it, try rewriting it in a new language. Think about a tool (software) that you would like to use, no matter how small or silly, and make it. There is so much pressure to know the newest and most popular languages and frameworks and have a clean GitHub repo full of complete, relevant, and useful projects. That is especially appealing if you’re looking for a job. Yes, you should have a couple projects that are showcase worthy and speak to your desire to competently code. You should also be able to speak to your desire to learn and solve problems.
At the end of the day, code is just a tool. No one faults a carpenter for having multiple hammers. I mean have you ever seen the garage of carpenter or maker; they are usually a glorious mess of projects in various states. Play and don’t fear clutter. Clean as you go and organize if you must. I’d rather have the GitHub of Doc Brown over Patrick Bateman any day. You can be a competent, intelligent adult and still play. If you don’t want work to become a chore, you must play.
From,
Zach Turner
Build on your own
Dear new developer,
Having a side project makes you a better developer. This is kind of a bummer, because when I get home from a day at the office, I don’t want to sit in front of the computer any longer. But if you can make it happen, even if only an hour a week, you’ll learn from building on your own.
Why? Because a side project lets you perform all the activities which go into a software product. You get to make all the decisions. Design, product, hosting, languages, frameworks—it’s all on you. If you had a deadline, this would be a burden. When you don’t, this is a learning gold mine.
Start by finding a problem you want to solve. For me, this is usually a database-driven web application, but what is important is that you are interested in applying the technology you choose to your problem. Think of a side project like taking up a new hobby that happens to involve code—a bit like a professional musician going to a jam session, but with screens and keyboards.
If you don’t have an idea for a side project, but have time and interest, find an outside project you can help. Ask around at meetups or check out organizations like Code for America.
If you do code, don’t feel you must make your project public. Potential employers may use it to evaluate you without your knowledge. If you make the code public, document its current state, especially if it is unfinished. This will make it clear to potential employers if a project is a work in progress.
If you don’t want to write code, write prose. A blog will let you explore new technologies or business domains. Writing familiarizes you with the community, helps you understand the use cases for a technology, and can establish you as an expert.
Don’t be afraid to let the side project go. I let go of a website directory I built. It was painful, but I didn’t have time for it. If you aren’t enjoying the project or don’t have time for it, let it go. An initial commitment of six months helps me get “over the hump” that I encounter starting anything. It also helps me avoid beginning too many projects—if I can’t commit for six months, I shouldn’t start it. If you’ve been building on your own for at least that long and you find yourself avoiding it, give yourself a month off. If that time away doesn’t spark renewed enthusiasm, let it go. If you have end users, make sure they can get their data. If it’s an open source project, find another maintainer or mark the project as clearly in hibernation. If it’s a blog, write a goodbye post.
Should you mention what you’ve built in interviews? Sure, like anything else, a side project is fair game to mention in an interview if it illustrates a skill relevant to the job. For instance, if you prioritize features for your side project by talking to users, that displays communication skills and user empathy.
What if you don’t have time to do a side project? That’s okay too. Building something outside of work is one way to get better at your craft, but certainly not the only way.
Sincerely,
Dan
Consistency is key
Dear new developer,
Sometimes you just have to grind.
It’s easy to find yourself beaten up . Development, while not physically difficult, can be mentally and emotionally taxing. You can really screw things up. You write software under pressure. Even when you’re part of a team, often you’re working on a task into which you alone have insight. No one else knows the problem as well. Asking for help will net you advice, but not necessarily a definitive answer. Deadlines loom. You’re learning on the job—figuring things out. There’s always a new technology stack or framework or language or technique or term to learn.
Phew.
How to navigate the command line in the most efficient way possible
How to read a regular expression
When to ask a question and when to keep pushing forward on the current problem
How to ask for a raise
How to search the Web
How to scan logs
How to stay calm in a crisis
This knowledge can’t be taught; it must be learned. You learn it by showing up every day.
This is true of any skill you want to gain. Do you want to be good at design? Writing? Public speaking? Find a way to practice every day or every week. Six months is the minimum commitment. It’s not too long, yet you’ll be more than a beginner at the end. You’ll have the context to know if you want to continue. Consistency of this sort has opportunity cost, however. Committing to writing a blog post every week means you’ll have less time to watch your favorite TV show.
I find it scary to commit sometimes. What if I choose the wrong technology? What if I don’t like writing a blog? The good news is I can stop. Especially early in your career, you can take a mulligan easily—you’re being hired for potential rather than skill set.
When I’m aiming for consistency , I like a paper calendar to track my efforts. I put a big fat “X” on it every day I show up. Getting to put that “X” on the calendar motivates me. It has even forced me to get up out of bed at night, just to keep a streak going.
Consistency gives you a chance to improve and permission to fail. If you are working on problems that are hard for you every day, you won’t hit a home run every time. Heck, you can’t expect to always hit a single. But if you can show up and put in the hard work, you’ll improve. If you write a blog post every day for a year, some will be good, some will be bad, and some will be horrible. But if 10% of them are good, that’s three times more useful content than regular good monthly blog posts .
Keep it up. Good things will happen.
Sincerely,
Dan
In conclusion
Practices help you improve a facet of the software craft. Whether reading code, empathizing with the users of your software, or communicating with nontechnical colleagues, these techniques don’t always come naturally.
You must practice them repeatedly, but when you do, they will get easier. You will begin to perform them intuitively. They’ll become habits, and then second nature.