Learning is part of being a software developer. Because technology and techniques are revised and updated regularly, self-education is important for succeeding at your current position and also for future opportunities. The first half of this chapter covers abstract aspects of learning, and the second half is tactical, including specific tools I use to continue my education.
Sometimes you’ll need to find a solution for a specific problem, such as how to concatenate two strings in an efficient manner. Other times what you are looking to learn might be more systemic, like how to leverage a new cloud service to save your company money.
Reading to level up your craft
Educating yourself with theory and others’ experiences to approach your work in a new way
Picking up industry terms and concepts to enable better communication
Mastering something new just for the joy of it
Not everyone learns the same way. I’ve had colleagues who loved watching videos to dig into a subject, while others find watching YouTube tedious, slow, and uninformative. Some software engineers reinforce their learning by writing down daily reflections, while others prefer hands-on tutorials.
The specific method you use to teach yourself is less important than finding a way to incorporate learning into every day of your software development career.
Never stop learning
Dear new developer,
At lunch once, I asked senior engineers and managers what advice they’d give to a new developer. One answered: “never stop learning .”
Like most good advice, it’s simple but not easy. It’s simple to remind yourself you must always be learning and improving, but I often find it difficult to carve out the time. However, trying to catch up is harder than investing time regularly and staying current.
If you are not interested in or able to learn new technologies and techniques, software development will eventually pass you by. I’ve seen it happen over the years. Perl used to be an in-demand programming language. Now the number of job listings mentioning Perl, a proxy of demand for the skill, are much fewer than they used to be; this indicates to me that this language is in decline.
You can still make a great living with such skills, but opportunities become fewer and fewer. You may need to move or decrease your salary expectations. There are still COBOL developers, but every year fewer companies need their services. And it’s not just programming languages which regularly rise and fall in usage. The software development process has changed even in the few decades I’ve been working, including sea changes like extreme programming, the Agile methodology, and infrastructure as code. An example of a recent revolution is the DevOps mindset.1
Bored—They simply aren’t interested in learning.
Frustrated or blocked—They can’t learn what they want to because of constraints, possibly organizational.
Tired—They have too much going on, and they need their energy for other parts of their lives.
Comfortable—They know what they need to know and are “punching the clock.” They are doing good work now, but not improving.
Shifting priorities—Other things take precedence; a new baby, health issues, or a family emergency, for example.
All of these make sense. You have a job to live your life; you don’t live your life to succeed at your job.
However, a shift in perspective, whether a new job or a new way of looking at your current position, can remove obstacles that may prevent you from learning. For example, if you are frustrated because you’re a software engineer in test but you are really interested in DevOps automation, find a tool to run your tests automatically. Talk to the infrastructure team and see how you can help test their infrastructure as code deployments.
If you want to incorporate learning into your daily life, the short answer is “Google.” The Internet is full of information about how to be excellent at software development.
Think about why you want to learn. Is it for fun? To find a better job? To be better at your current position? To test out your theories? To solve your own problem, scratch your own itch? Because you want to make the world a better place? Finding this intrinsic motivation will help you continue when you encounter difficulties.
From the why comes the what. What can you learn that will help you achieve your goal? Is it a business domain? A new technology? An old technology? A framework? A mindset?
After the what and the why comes the how. Do you learn best by watching videos? Reading text? Working through code tutorials? Blogging? A side project? Reading code? Try each of these if you don’t know. Find a method which provides useful knowledge that you'll remember.
Execute. Find the time and the willpower to take the why, the what, and the how, and begin. When you fail, focus on the why to stay motivated. Options for carving out time to learn include scheduling daily time, building something yourself, ordering books on technology for bedtime reading, or participating in online communities.
Figure out how you want to learn, and never stop doing it.
Sincerely,
Dan
Build expert intuition
Kim Schlesinger is a site reliability engineer at Fairwinds. Prior to Fairwinds, she cofounded <div>ersity, a hiring platform focused on diversity, and was an instructor, developer, and curriculum designer for the Web Development Program at Galvanize, a codeschool based in Denver, Colorado. In her spare time, Kim is a CrossFit athlete and the Head of Education and Content for Develop Denver, a two-day conference for developers, designers, strategists, and tech leaders.
Dear new developer,
I know you worked hard to get where you are. You are self-taught, you earned a degree in computer science, or you graduated from a coding bootcamp, and your hard work helped you master the skills required to be a “junior” developer. (I prefer the term early-career developer, but I’ll use the terms junior and senior developer.)
Whether you are still searching for your first dev gig, or you’ve been at your first job for a while, you’re probably wondering what it will take for you to be a senior developer. There are lots of factors that contribute to being a “senior,” but the most important one is time.
It takes time to become a senior engineer because you are developing what behavioral economist Daniel Kahneman calls “expert intuition.” Expert intuition is knowing how the story ends because you’ve read the book many times before. Expert intuition means that you can see a technical problem and you just know how it can be solved. Expert intuition is the difference between a junior and senior developer.
A Regular World + Many Opportunities to Learn + Frequent Feedback = Expert Intuition
Let’s take a look at what these things look like for a new developer.
A regular world
A regular world is one where there are a set of rules you can learn. For a new developer, that means a job where you can observe and begin to navigate your company’s culture. It also means having an opportunity to write code with a few programming languages, frameworks, and approaches to deploying software. Even if your company’s culture isn’t great, or you’re not writing code in the language you prefer, your early experiences will help you figure out what you do and don’t like in a company and if you’d like to specialize in a specific part of the software creation process or remain a generalist.
If you’re still searching for a job, you can create a regular world by setting aside time each week to work through exercises on a learning path like Exercism, contributing pull requests to open source projects or civic hacking projects through Code for America, and networking and applying for jobs.
Many opportunities to learn
As a new developer, your most obvious opportunity to learn is to write code and work on technical projects. Definitely do that and know that another way to learn is to observe engineers that are more senior than you.
Pick one colleague you admire, and notice how they learn new concepts or technologies, how they ask questions in meetings, and what they do on a project before they start writing code. Ask to pair with this person, take them out to coffee, and ask them what technologies they’re curious about and how they approach writing code. As soon as you identify some of their signature behaviors, start to emulate them.
If you’re still looking for a job, find a streamer you like and copy their behaviors. I’m a fan of Coding Garden with CJ and Suz Hinton.
It’ll take time for you to make these behaviors your own. However, being intentional with your developer habits and mindsets is a faster path to becoming a senior engineer than other, more conventional, learning opportunities.
Frequent feedback
The final element that will help you develop your expert intuition is getting frequent feedback . You can get feedback from other developers on your code through code reviews and on your technical and nontechnical performance through regular one on ones with your manager. You can reflect and improve on your performance by keeping an end of the day journal where you write down what you learned and how you felt during the day.
It takes time
In June of 2018, I took a job as an apprentice site reliability engineer. Before that, I was a full-time educator and part-time JavaScript developer. I assumed it would take me a few months to figure out how my new company operated and six or so months to get a grasp of cloud computing in AWS and Google Cloud Platform, Docker, Kubernetes, and the wide variety of continuous integration/continuous deployment platforms.
At the time I write this, I’m a year and a half into the job, and although I am more skilled than when I started, there is still so much for me to learn and do. Moving from web development to site reliability engineering is a big transition, and I underestimated how hard it would be. I’ve made peace with the fact that it will take me years before I will be an expert. New developer, you’re starting a new career, and it takes years to grow into your professional self. It takes time, so be patient, and remember the ingredients for developing expert intuition.
Sincerely,
Kim
Teach and learn
Dear new developer,
I’m always thrilled when new developers help others. When they return and mentor at their bootcamp or present at meetups, it helps them and their audience. Everyone has something to teach.
You may think to yourself: “No! I am learning so much right now. I don’t know anything. There’s no way I could teach anyone something.”
False.
There are a number of ways that a developer can teach, even at a job where they are learning something new every day. I’ve found that learning to do something myself is shallow knowledge, whereas knowing something well enough to explain it to others is a much deeper form of understanding. In the former case, I can gloss over things, as long as it works, but in the latter I really need to understand to explain.
Why do you have only one server?
Why are you using that language for data processing and this one for web development?
Why are we hosting git on our servers instead of using GitHub?
I always love when a new person joins a team because they are the antidote to the “fish in water” syndrome. Because they’re embedded in it all the time, fish don’t see water. In the same way, teams don’t see inefficiencies. I’ve lived with solutions for so long that I don’t remember why they evolved in the way they did. A new team member asking questions causes me to rethink decisions. One time I led a team that used Trello, a free general-purpose tool, for project management. We’d customized it, built an integration, and added layers of process. A new developer came in and basically said, "why don’t we use Jira, a tool built for project management?" Using Jira let us work with instead of against our project management tool.
Another way you can teach is to offer your experience with new technology. You might say something like “what do you think about trying <technology>?” Discuss how using a new tool can help build better software. Chances are high that if you are a new developer, you have experience with newer, popular technologies. Keep an eye out for where they might be a fit but do it tactfully. Don’t proclaim “the way we currently do this is bone-headed. We should do it this other way.” That’s not helpful.
For example, I met someone at a conference who was working to introduce a modern software technique. The software he worked on was written in ColdFusion, an older web technology. The company was profitable. But he thought the software development process could be modernized. He introduced test-driven development (TDD). There was resistance to this new idea among the team. So he was implementing it himself and showing how it produced more robust, maintainable code. His hope was to convince the rest of the team with data and results. He did this after consulting with the team and presumably with the blessing of his manager. You don’t want to secretly rewrite a whole subsystem and surprise your team with “improvements” or change the codebase from tabs to spaces (or vice versa) leading to merge conflicts for everyone. Introducing new technologies by dogfooding them yourself can convince skeptics.
Another way to teach is to niche down and find neglected areas of a codebase. Ask other team members “what parts of the code are scary?” Learn them. Work through that code and document what is happening. Bonus points if you write tests. Doing this helps you learn the codebase and become a local expert. Later you can help others understand it.
An aside: Some people are unwilling to learn from people they consider “new” or “junior,” but some people have a hard time learning from anyone.
All of these require you to both teach and learn, which is as it should be; rarely is anyone solely an educator or a student. Also, as a new developer, be humble because you don’t know what you don’t know.
When you are starting out, you are unlikely to have the full context for how and why a system or codebase is the way it is. Never trash code, even if team members are doing so. You don’t know the constraints under which the code was written. When I am new to a team or system, I couch any suggestions in terms of “This is what I think, based on my knowledge of the system. What do you <person who has been working on the system for a long time> think?”
Humility doesn’t mean that you are always the student. Be tactful, ask questions , learn, but realize you have something to teach. Everyone does.
Sincerely,
Dan
What is your woodlot?
Dear new developer ,
You can’t eat gold like you can the bounty of trees in fruits, nuts, maple syrup, and various edible mushrooms and herbal treasures of the woodland. You can’t warm yourself with gold. You can’t bask in the shade of gold. You can’t make fence posts out of gold. A gold house would be mighty expensive. You can’t make a windbreak out of gold. You can’t make furniture, violins, guitars, wall paneling, picture frames, gun stocks, tomato stakes, flooring, barns, chicken coops, and hog houses out of gold. You can’t mulch a garden with gold leaf. Gold does not take in carbon dioxide and give off oxygen to preserve an environment we can live in. Gold does not provide habitat for millions of wild animals and zillions of insects necessary for a sustainable environment. And in fact, you can make methane out of wood much more efficiently than ethanol out of corn. All gold can do is go up and down in price and invariably it turns out to be a poor investment, as many panic buyers learn the hard way.
In short, it’s better to have a skill that can be used multiple ways, like the woodlot, than one which can only be used for one purpose, like gold. Knowing how to learn is a software developer’s woodlot. Knowing one particular technology is like owning a bar of gold.
Domain knowledge
Theoretical expertise
Practical knowledge
Leadership and teamwork skills
Domain knowledge is understanding the real-world problem domain. So, if you’ve worked, as I have, in a real estate brokerage, you understand how the business works—who pays for what, how money and effort flow, who the main players are, and what they are named. This is useful because you understand how a software system maps to the real world. That makes communication with users and other stakeholders easier and allows you to avoid expensive mistakes made when the application doesn’t map to reality.
Domain knowledge changes slowly over the years and decades. I haven’t worked in real estate for years, but if I went back, the concepts and major players wouldn’t have changed. You can acquire this knowledge by reading and talking to business domain experts. Focusing on a technical problem and solution is a missed opportunity for you to deepen your domain knowledge. If you can, stay in a domain long enough to build understanding. The longer you are steeped in a given area, the more valuable you become, as you gain experience with the concepts and solutions.
Theoretical expertise is the ideas and practices fundamental to software development. I’d put abstractions like algorithms and data structures, specific technologies like distributed systems, database indices, and HTTP, and best practices like automated testing and requirements gathering into this category. This type of knowledge lets you understand a system even if you haven’t seen the nuts and bolts of it.
Of course, the type of general technology that is most useful to you depends on your problem area. The technology knowledge needed by a chipset engineer is different than that of a UX designer. This knowledge is good for years. I find the best way to learn this is to read and study classic books and articles, but hands-on debugging is helpful too.
A formal CS degree is useful as well. I don’t have one, and every time I must learn new theoretical knowledge, I have extra catching up to do. This catch-up learning requires understanding imposing jargon. Big O notation is an example of this. When I first heard about it, it seemed scary and abstract, but after a bit of study, it’s really just counting loops.
Specific technology knowledge is narrowly focused. These are the keywords on job postings and what consultants chase after: Elm or Elixir, Rails or React Native, Kubernetes or KVM. I’m of two minds about this knowledge. On the one hand, if you pick the right one, you will be in demand, which leads to career choices and salary growth. On the other hand, new technologies are constantly released, and keeping up with all of them, let alone gaining expertise, requires large time investments. I also feel like many developers can get up to speed on a new technology in a couple of weeks, at least enough to be effective at making changes to an existing system.
However, I also have sympathy for folks seeking specific expertise. As mentioned, any competent software developer can pick up any language in a short period, but understanding the idiosyncrasies, libraries, and community practices take time. You may find it cheaper to pay someone who has acquired that knowledge elsewhere. As you can imagine, this type of knowledge ages quickly. Videos, conference talks, and tutorials all help me learn specific technologies.
Leadership knowledge is orthogonal to software expertise. Since applications are built by human teams, knowing how to lead engineers toward business goals is a valuable skill. This knowledge includes specific techniques like agile development and “one on ones” and more general topics like how to connect with people and how to navigate politics.
This knowledge has a long half-life and will pay dividends throughout your career. Books and the school of hard knocks have taught me the most about this aspect of software development. One time I was managing a new developer; I’m very goal oriented and I wanted to learn what her goals were. I’m afraid I was a bit too enthusiastic and didn’t read her nonverbal signals indicating that wasn’t really how she wanted to be managed. This caused team turmoil; I learned that you need to manage employees how they want to be managed, not how you would want to be managed.
Just like the woodlot has many more uses than the pile of gold, learning general skills has more value than knowing any technology or technique.
Sincerely,
Dan
Avoid being an expert beginner
Dear new developer,
An “expert beginner ” is an authority with nontransferrable skills. They have been at one organization and have influenced that technology environment so it reflects their knowledge rather than best practices. An expert beginner rarely interacts with the larger software community.
Much like fish isolated in caves become adapted to their environment, a developer who is an expert beginner is intimately familiar with the systems they work with. They can make those systems dance. But just as those fish can’t survive in a normal pond, the expert beginner’s knowledge also limits them. They’ll use tools in ways you shouldn’t, be ignorant or dismissive of best practices, and in general build suboptimal software.
The concept of the expert beginner, originally espoused by Erik Dietrich,3 resonates with me. I’ve spent most of my career in small companies. That fits best with my desires and my life goals. But I’m acutely aware that as I become more experienced, I am one of the most senior technical people in the room. This would be a problem if I believed that I had all of the answers; this is what the expert beginner believes. You must always be open to new ideas.
An easy way to avoid this fate is to engage with peers in person. Conversations over coffee with former coworkers don’t dig as deep technically as they might have when I’d been working with them. But by keeping in touch with my work network, I can avoid the trap of thinking that because I’m at the “local maximum” of software development expertise at a small company, I’m also at the “global maximum.”
Going to a local meetup
Joining an online tech community
Reading and writing blogs
Reading and answering questions on Stack Overflow
Following smart people on Twitter
Seeking mentors
Having lunch with interesting people
Going to and speaking at conferences
If you have experienced developers on your team, that is a high-bandwidth way to level up: ask to pair with them, pepper them with questions, read pull requests that they file. Be aware that they have their own blind spots, as we all do.
Unfortunately, not every work environment has senior developers. If that’s the case, improve yourself by engaging with the larger software community, and avoid being an expert beginner .
Sincerely,
Dan
Pattern match to be a just-in-time learner
Dear new developer,
In the context of manufacturing , the phrase “just in time” means delivering the right parts to the right plant at the right time. This revolutionized manufacturing. Just-in-time learning means that you learn what you need to know at the right time, that you pick up new knowledge when you need it. This means that you can perform tasks outside your core competency. You may not do them perfectly, since you are learning as you go, but you can get them done. And sometimes you just need to get a task done. An example might be setting up a deployment pipeline for your application. Sure, it’d be great to have an expert around to do this for you, but often there’s no one else; either you’re on a small team or the expert is unavailable.
Pattern matching helps you learn in a just-in-time fashion. By drawing from your existing store of knowledge, rather than having to start from first principles, you accelerate your ability to deliver. Pattern matching helps you do this by looking at tasks, thinking about how you’d do them in a different context, then mapping the actions to the current situation. As you gain experience, you’ll begin to see these patterns.
A dependency tree, usually stored in a text file
A central online repository, or multiple repositories, where shared code lives
Private repositories for proprietary code
Commands to update individual packages or entire application dependencies
Crucially, I also know why this tool exists—to allow software developers to build on top of others’ efforts in a repeatable, manageable way. I don’t really need to master each dependency manager because I can map between the ones I know (maven and bundler) and the ones I’m less familiar with (composer and npm). I explore by analogy and learn just enough to do what I need to do, which means I’m not overwhelmed by each new tool.
For example, if I need to figure out a way to update a single package using npm, I can search with terms drawn from my knowledge of maven. Pattern matches rely heavily on the power of the Internet and common terminology. When searching, I will use words that span technologies. Sometimes I need to find a translation between two terms that mean similar things, such as function and method. Pattern matching requires knowing how to Google well.
You can apply such matching across software development in general, not just with specific tools. Every language has structures for storing data in memory. Every project has a production environment and a way to deploy code to production. Every system has an architecture.
However, when you pattern match, be aware of your limits. Just because every language has a list data structure doesn’t mean that the performance, memory usage, or maintainability characteristics of that list are the same. The analogy helps you get started, but dive in deeper to understand nuances.
Be a just-in-time learner. Focus on what’s in front of you and learn how to accomplish that. Look for patterns and analogies between past experience and your current problems.
Sincerely,
Dan
Help, I can’t learn something because it is boring!
Dear new developer,
Focus on the big picture—This helps me stay motivated. Why am I doing this? How is it connected to the larger goals of the organization? Who is this going to help when it is finished?
Notice the fun parts—You can’t, of course, do only the fun parts, but you can notice them and smile. For example, I am not a front-end developer. I find CSS to be alternatingly frustrating and boring, but there are times when I have to mangle it. Err, I mean modify it. I enjoy learning the basics, like the difference between padding and margin. And it is a good excuse to have a pleasant chat with other team members with expertise in CSS.
Take breaks when you need to—If the deadline isn’t tight and there are other tasks on your to-do list, take a break and cross one off. Remember that your career is a marathon, not a sprint.
Automate what you can—Don’t go overboard but write a shell script or shell alias. Especially if you’re debugging something, this automation will help you focus on the intrinsic work you are doing and can make the whole process less tedious. However, avoid overly elaborate automation—you don’t want to take three hours to write a script to automate a task that would have taken you one hour manually and which you won’t have to do again.
Make sure what you are learning remains relevant—Depending on how long you’ve been learning this technology, you may want to make sure what you are doing is still needed. This doesn’t apply if you have only been researching for a few hours, but if it has been a few days or weeks, other priorities may take precedence. Be prepared to answer the question “well, how long do you have left?” with some level of confidence.
Sometimes you must learn something that you find boring. Hopefully, these tips will help make it a little easier.
Sincerely,
Dan
Your team will teach you
Dear new developer,
Technical tools like languages and frameworks
Business domain knowledge
Approaches to problem-solving
Understanding of the problem
Stakeholder empathy
These are all reasons to take a job with a team. The amount you can learn from other people, even those with the same or less experience than you have, is more than you can learn on your own. After all, if each person on the team has one year of experience, and there are three of you, you each collectively have access to three years of experience.
If there are senior people on the team, observe how they work. They aren’t perfect, but you can benefit from learning how they operate. If the senior folks are unavailable to meet face to face, you can still read their code and pull requests. Get familiar with git log and try to understand their reasoning.
As you work with team members, try to understand and appreciate where they are coming from, especially when they provide different perspectives. For instance, I worked with a small team on an image recognition application, and that was the first time I achieved a real appreciation for the use of a NoSQL database. I’d always dismissed NoSQL solutions before then. Because I worked on a team with different backgrounds than I had, I was able to learn the ins and outs of a new technical stack, which has proven useful since. Your ability to grasp how others solve problems can help the team to arrive at the best possible solution.
Learning from your team members is a great way to access experiences that you can’t get or simply haven’t had yet.
Sincerely,
Dan
Use an RSS reader
Dear new developer,
Use an RSS reader . By doing so, you’ll set up a centralized information hub that you can access when convenient for you. When you run across an interesting source of information like a blog, add it to your reader. Then, whenever a new post is published, you’ll be notified. You don’t even have to remember the site URL. The RSS reader polls the site and, when there is new content, will display it to you.
RSS stands for Really Simple Syndication and was standardized in the early 2000s. I use the NewsBlur reader, but there are a few good options. It’s easy to move between them because the format of the list of monitored sites is standardized.
One of the best things about using an RSS reader is that it lets me go to the content when I want to, rather than having the content come to me, as it would if I were subscribed to a mailing list. It is also a single application to open. Instead of having to go to different places on the Web, I go to one. An RSS reader is similar to Twitter or Reddit, but less noisy, with fewer controversies, more control, and richer content.
RSS readers are not only for keeping track of blogs. You can use a reader to keep tabs on your favorite online community discussions, tags in Stack Overflow, or popular news sites. Using tools, you can convert social media streams such as Twitter searches to RSS feeds and then consume them with your reader.
I primarily read RSS feeds on my phone. Reading on my mobile device takes advantage of scrap moments of time, such as when I’m waiting at an appointment.
Friends or acquaintances who blog—I know these folks and want to make sure to see whatever they’ve written. These may be former colleagues or folks I’ve met at a conference.
Corporate announcements—If I’m using a company’s services, I subscribe to their blog. I can then learn about new services, updates, or pricing changes. Among others, I subscribe to the AWS and GCP blogs.
Long-form, rarely updated blogs—There is absolute gold in these articles, which have changed how I think or feel. Charity Majors, for example, has a great blog4 covering a variety of topics from engineering management to observability. But she posts infrequently. Adding her site to my RSS reader makes sure I won’t miss anything.
Niche experts—If I’m interested in learning a specific technology, I subscribe to focused blogs. For example, if I wanted to dive deep into Ruby on Rails, I’d subscribe to Nate Berkopec’s blog and the Test Double blog.
Companies I want to follow—Sometimes I’ll run across a company and think “wow, that’d be a great place to work.” If they have a blog, especially an engineering blog, I subscribe. That way I’ll be reminded of them whenever I visit my reader. The next time I’m looking for a job, I will have a few interesting companies on my radar. RSS is also useful for following your company’s competitors.
RSS is a venerable format , but one that can still do great work for you.
Sincerely,
Dan
Listen to podcasts
Dear new developer,
During your day, there are times when your body is occupied, but your mind is not: doing the dishes, exercising, or driving.
Exposing you to new ideas and concepts
Giving you an awareness of new technologies and tools
Letting you learn from others’ wisdom and experience
Podcasts are not a replacement for code tutorials or other hands-on practice. Rather, podcasts expose you to new concepts and give you terms for further research. Sometimes just knowing that something exists is enough. For instance, I learned about a Ruby library called graphiti which makes creating APIs trivial from a podcast. I don’t need this knowledge right now, but in the future I might. Now I know the gem exists and can read the documentation with simple Google search.
Domain specific—If you work at a startup disrupting the real estate industry, listen to a podcast or two about real estate, such as the BiggerPockets podcast. Car insurance? Fashion? In each case, find focused podcasts. You don’t need to be an expert in the business domain, but the more you understand it, the more able you’ll be to communicate with subject matter experts about the nuances of the problem space and therefore build the right software.
Technology specific—If you are writing code in Ruby on Rails, listen to podcasts about Ruby and Rails development, such as the Ruby on Rails podcast. The same for JavaScript, Erlang, or Lisp. These podcasts elevate your development skills in the subject language by exposing you to useful tools, techniques, and libraries, just as I learned about graphiti. I like to email myself new discoveries when I listen to these kinds of podcasts.
General software development—There are a lot of these. Some are more technical, like Software Engineering Radio, and focus on architecture or scalability concerns. Some are less technical and discuss the human side of software development, including leadership and communication styles, such as Authority Issues. These are the podcasts I am least likely to unsubscribe from when I switch jobs, because the topics are broadly applicable to software engineering.
Don’t feel that you must listen to every episode—I don’t. I pick and choose based on the show notes, topics, and guests . And don’t feel bad about unsubscribing when you switch jobs or industries, or even if a podcast is simply no longer of interest.
Podcasts are a great way to get exposed to different software development concepts during downtime.
Sincerely,
Dan
Subscribe to link newsletters
Dear new developer,
Email newsletters can be a great way to learn about a specific domain. Experts gather articles and information about relevant topics and share them with you. They sift through much more of the Internet than you could on your own. These are typically delivered weekly. I’ve found these for many topics, including software development practices, security, AWS, and career skills.
These newsletters don’t take any effort on your part, other than signing up of course. Once a week you receive an email full of links in your inbox. Subscribing is a low-effort way to learn about new technologies, familiarize yourself with an area, and get links to share with your team.
Pick and choose—There are many because developers’ attention is valuable. Search around for a bit before you subscribe. Good terms to search for are “<subject area> weekly newsletter” or “<subject area> email newsletter.”
Read the archives first—This will give you a preview of the content and the voice of the newsletter.
You don’t have to read every link—I find it overwhelming when I receive an email with 50 links. Scroll through it and read only the especially interesting ones.
Share the wealth—Share pertinent links with your online community, your team, or a former colleague.
Use it as a source for your RSS reader—When an information source is linked to that seems worth keeping track of, add it to your RSS reader.
Explore—Use the newsletter to explore a new technology or area of software development. The regular, curated content will introduce you to both jargon, useful for further searching, and people writing well about the topic.
Don’t be afraid to unsubscribe—Easy come, easy go. If you don’t use a technology any longer, or aren’t interested after doing initial research, don’t clutter up your inbox. You can always subscribe again if you miss it.
If you are looking for a newsletter for a topic and can’t find it, you could also start your own, but mentally prepare to have few subscribers when starting up. TinyLetter is one tool which can help. Plan to spend time finding and curating links.
I find these email lists especially helpful to tune into a tech community. They are a great way to keep on top of what people are talking about without you having to spend any time searching.
Sincerely,
Dan
Read great books about software development
Dear new developer,
You won’t learn the latest development techniques from books. Those are described online in blogs or videos—or possibly in papers, if you work in an area where academia is doing research.
Nor will you learn specific approaches that you can put to immediate use to solve a current work problem from books. That kind of assistance is found in docs, GitHub issues, or Stack Overflow.
What you will learn from the great books of software engineering are timeless practices. You’ll learn how to dig deeply into a topic and how to take what is in a book and apply it.
I’ve joined discussion groups about software books, which can be a fun way for people to share their experiences. Such groups also hold me accountable; sometimes great books, like Gödel, Escher, Bach, can be hard to finish.
The Mythical Man-Month—This book covers what is arguably one of the first major modern software projects. This book explores the difficulties of building software. It’s the source of the commonly cited fact that when a project is late, adding more developers will increase communication needs and thus delay it further. It is sobering reading when you compare what was done decades ago to today’s practices.
The Pragmatic Programmer—This book discusses software best practices and ways to level up your personal software development skills. It has a great set of checklists.
Refactoring—This volume explores refactoring, a specific type of software maintenance. In the same way that you need to take care of your car, you need to maintain software. How to do it, when to do it, how to talk about it—these are all covered.
I read these books in dead-tree format. I find it best to have a pen so I can underline statements that make a lot of sense to me or that I want to consider further. I dog-ear relevant sections. And, unlike a great novel, I don’t speed through them. One chapter a day is moving fast.
Finally, finding good books to read is a great way to connect with your team or community. Ask engineers who you respect what books they’d recommend reading. Reading such books deepens your understanding of the craft of software.
Sincerely,
Dan
Listen actively
Dear new developer,
Listening with focus and intention is a great way to learn. When you can really dive deep on what a fellow team member knows, whether in a chance encounter or in a meeting, you’ll learn so much. Here’s how I listen with focus and intention.
First, stop multitasking. Close the chat system and your email. If you’re in person, shut your computer. As best as you can, set aside all your worries, concerns, and to-dos. You’ll be able to pick them up again after the conversation, I promise.
Then, take notes. I use my computer if this is a video chat. If I’m in person, I use pen and paper. What should you take notes on? This isn’t a college lecture, so you don’t need to capture everything. Write down salient points, ah-ha moments, and terms that you might want to review in the future. Note the date of the conversation as well.
As someone is talking , I write down concepts or terms I don’t understand. You want to capture these in the moment, but don’t interrupt the speaker. When I am listening, I take each statement and make sure I understand it. If not, I capture a note. It doesn’t have to be a long one, just enough to remind me of my question.
When the speaker reaches a natural stopping point, or if they ask for questions, I reach for my notes. I try to provide context. I’ll say something like “you were talking about the OAuth process and you mentioned pixie something. What is that?”
If it is a smaller group, I may interrupt more often. I’ll often rework what they said in my own words so I can be sure I understand it. “Can I repeat what you just said to make sure I understood it? You’re saying that for the basic plan, everything, even the database, lives on one server. Is that correct?”
With active listening, you interact with the speaker. However, you want to tweak this interaction based on the context. If it is you and a teammate, then the conversation can be participatory. You can break in whenever there’s a pause for clarification. If it is a company-wide meeting, there’ll be less interaction. You may still want to take notes, but the follow-up may be additional research or conversations with team members rather than questioning the speaker.
If the conversation is happening over a video chat or conference call, then you have more options. I like to record these if possible. Then, if needed, I can go back and figure out what was said. Make sure you get permission to record. And if you are on a video chat, turn on your video. Even though video isn’t as high bandwidth as in-person conversation, you can still pick up contextual clues from it. Is the speaker rolling their eyes as they cover a particular topic? Are they frowning? Smiling? All these are useful nonverbal signals that should inform your responses. They’re all absent if you don’t have video turned on.
If a conversation results in a decision or assigns folks tasks, I write up a summary and send it over email. This allows everyone to be clear on any required actions. If, on the other hand, it is an informational discussion and other team members may be interested in the topic, writing up a document and putting it online is a good idea. But both of these outputs should be secondary to listening and understanding what is said.
Sincerely,
Dan
Learn two languages
Dear new developer,
When you know one programming language, you can get a lot done, especially if the language is prevalent. For example, in web development, the dominant language is JavaScript. In system programming, it’s C. These languages will be around forever, and you’ll always be able to get a job if you know them.
You can also have a great career with niche language knowledge. You might have to search a bit harder to find a job, though. Examples of such languages include ClojureScript for web development or Nim for systems programming.
Knowing only one language is like living in the same town all your life. You can be happy and productive. Yet exposure to a different city expands your mind, illustrates divergent living patterns, and helps you understand the strengths and weaknesses of your hometown. Sometimes what we assume are universal truths are simply what we are familiar with.
Software engineers are similar. They are often dogmatic about the virtues of technologies and frameworks, simply because they know them. We also are relatively quick to judge, sometimes with no more justification than the latest blog post we’ve read. This snap judgment also occurs because we must regularly make decisions about technologies with imperfect information. But you should not put down things you don’t understand.
I cut my teeth writing Perl. I wrote a lot of it for my first job. Then I wrote Java. The first Java classes I wrote were, to be charitable, not idiomatic. For instance, rather than using classes, I leveraged hash maps and lists for all my data structures. I remember another engineer reviewing my code and commenting “that looks a lot like Perl written in Java.” I didn’t know any better, so I’d mapped the solution from my first language onto the second.
Let you see the strengths and weaknesses of your first language. Every language has these, but when you have no basis for comparison, they’re harder to see.
Inform the code you write in language #1 with concepts from the new language. For instance, Perl supported classes, and using classes in Java made it easier to see their usefulness.
Make it easier to learn a third language, should you choose. You’ll see what is common between languages and what is unique.
Illustrate different approaches to common problems. How does each language deal with encapsulation? With dependency management?
Teach you how languages fit certain problems better than others. Perl is fantastic for text processing. Java is better for large-scale systems.
Make you less passionate about your first language. This may seem like a strange benefit, but learning multiple languages reinforces the fact that a programming language is only a tool. You shouldn’t fall in love with a tool.
Make it clear what you understand about language #1. If you can’t implement a solution in language #2 that you wrote in language #1, did you really understand it?
When you are learning the second language, it can be helpful at the start to have a mental map between language #1 and language #2. “I know that there’s a way to iterate over a list in Perl, so there must be a way to do so in Java.” This will also help you learn common software terms, such as “iterate.” Knowing these helps with searching the Web.
Which new language should you learn? That depends on where you want to take your career. Ask your team to see if there is more than one language used in your employer’s systems. If you want to work with data, learning SQL, a database query language, is a good idea. If you want to work at a certain company, find out what languages they use and learn one.
You can also learn a new language just for fun. For me, a side project is a great way to dig into a new language and take it beyond the tutorials. Tutorials teach me setup and syntax, but to really learn a language, I need to use it for a task where I’m not simply following instructions. By reading the docs and searching the Web, I map past experiences and the written word to my current problem space. I then really start to understand how to use a language. Some examples of mind-bending languages that might be fun to learn are Haskell, OCaml, Prolog, BASIC, and C.
The benefits of “learning a second one” apply not just to languages but all other parts of the software development process. Learn at least two of everything—databases, frameworks, development methodologies. The increase in perspective is worth the extra effort.
Sincerely,
Dan
In conclusion
As a developer, you’ll need to learn throughout your career. Over the years as technology has changed, I have spent time, energy, and money making sure I understood the shifting landscape. At the start of your career, there’s a lot to learn, but you start building good habits.
At the same time, it’s worth acknowledging that you can’t learn everything. The world of software is too vast. When you reach the limits of your knowledge, reach out to team members and your communities for help.