What’s your best advice for a new developer?

Dear new developer,

Dev.to is a relatively new community of developers. A few years ago, someone on that community asked for advice for junior developers, and I found the answers fascinating. Here are a few of my favorites.

People should respect you. It’s your right to push back against disrespectful interactions. If it’s waved away with “oh, [person] is just like that,” know that a) that is bullshit and b) both the person being disrespectful AND the one dismissing it are wrong. – Sarah Mei

Respectful communication and interaction is the foundation of trust, which is the foundation of team building, which is the foundation of software delivery.

Not getting your pull request through code review first time is okay. Everybody has their own approaches to problems, and a comment on your code review saying “X could be improved by Y because Z” doesn’t necessarily mean you’re not a good enough developer for only thinking of X, rather than Y. It’s usually more a case of your haven’t encountered a scenario that leads you to see the reasoning Z that causes you to use Y over X yet. – Aidan Walters-Williams

We all have something to learn. And our code is not ourselves, so when someone tries to improve our code, they aren’t attacking us.

Reporting a problem you’ve discovered is good, thorough analyses are better, proposing a solution is best. It doesn’t have to be right, it just has to start the discussion. – Dian Fey

It’s always good to go a step beyond reporting a problem because a) additional investigation may reveal it isn’t actually a problem and b) if it is a problem, the more you provide up front, the easier it will be for anyone trying to solve the problem (including future you) to replicate the context and hence investigate the problem with less effort.

There are a lot of great gems in the post.

Sincerely,

Dan

You’re going to put some plates in toasters

Dear new developer,

I saw this insightful tweet:

The whole thread is worth reading, but you get the basic idea. Sometimes you don’t know what you don’t know.

When I think back over the years, I am amazed at how many things I can do without thinking now that would have been baffling to me at the beginning of my career, including technical and non technical knowledge). This list includes:

  • navigate files and directories work
  • examine an HTTP call
  • determine the performance characteristics of an application
  • refactor an application
  • architect a large application
  • run a meeting
  • plan a project
  • exit vi

The road is long. And I still put plates in toasters periodically.

Recently at work, I energetically revised a planning document, adding what I thought was a ton of insight and value. Later I found out that the value I added was actually negative and that I’d done more harm than good to the organization’s goals when adding my thoughts. Man, was that a humbling and learning experience. Actually, that was more like putting a fork in a electrical socket than putting a plate in a toaster.

Much of what I know is at a high level with the idea that I can dive in (using resources like Google or Stackoverflow or a mentor) if I determine a need. Just knowing that something exists means that I can leverage all the great learning resources available if I see a place where it might appy. I also do a lot of pattern matching, where I compare how one system or process worked and see if and how that knowledge applies to a new problem.

So when you find yourself floundering, take a deep breath, forgive yourself, and dig in to learn. Foundational competence is something that you will acquire with time and study. But until you do, you’ll be putting plates in toasters.

Sincerely,

Dan

Learn an IDE

Dear new developer,

Just like you should learn a text editor, you should learn an integrated development environment (aka IDE). This is typically a standalone program focused on one or more programming languages. They range from free to a couple of hundred bucks in pricing.

Using an IDE will give you the following benefits:

  • It will be easier to navigate a project. Typically IDEs have a tree view of the entire project. Especially if you are not familiar with the command line, having this may make it easier for you to see how pieces of the project fit together. If the language supports it, an IDE can provide powerful searching capabilities, allowing you to see where a function, method or class is used.
  • Often these have refactoring support. Refactoring allows you to easily rename variables, functions/methods and files. If the language or IDE support it, references to the renamed entity can be updated as well. This will help make the code more fluid.
  • Debugging and code inspecting capabilities can be very useful. You can walk through code that is running locally and see the state of variables and make function calls. This is especially helpful if you have a test that can drive the code and replicate a bug. You can also, if the language supports it, connect to remote servers. (Many languages have command line debuggers as well, but it’s usually easier for a new developer to use an IDE.)
  • The IDE can provide text manipulation functionality. For instance, if you want to add documentation comments to every method, or an easy way to generate boilerplate methods, IDEs can provide this. It’s often easy to customize to your needs as well.
  • Easier learning the language or framework. If you are not sure of the exact name or syntax of a library call, an IDE can suggest it (often based on you typing a few letters). The documentation is often integrated as well, so you can, for example, see the javadoc by mousing over a method call (in a Java friendly IDE).

Obviously, as you see above, an IDE is very powerful. It’s also very tied to a language and the language’s features. If you are using a dynamic language (PHP, ruby) your IDE will have different capabilities than if you are using a statically typed language (C#, Java). But in either case, mastering your IDE will make it easier to write and debug code on your development computer.

Sincerely,

Dan

“It never gets easier, you just go faster.”

Dear New Developer,

Congratulations! Let’s take a moment to celebrate the decision you’ve made to launch or redirect your career. What lies ahead is a lot of hard work, satisfaction, the occasional desire to throw your laptop out a window, and a ton of learning. That’s true of most professions, so you’re also in good company.

As a developer, you will solve a thousand puzzles, and then a thousand more. Your brain will stretch and grow. You will dream about databases or pixels or curly braces. I once had a dream where I was walking down a hallway, but the hallway was my code. It was a good dream. I found a bug.

Greg LeMond, a pro cyclist and three-time Tour de France winner, once said something about cycling that I want to share with you: lemond

“It never gets easier, you just go faster.”

In so many ways, that describes a career in software. The puzzles you struggle with today will be easy in a month or a year. You’ll learn new patterns and best practices. Then you’ll take on new, harder challenges. You’ll struggle with those and learn and grow. Then you’ll start the cycle (pun intended) all over again.

Something I’ll add, though, is that you’ll be able to approach later challenges with more experience and confidence. What we bring to our jobs is an accumulation of skills and experience. This isn’t linear. It sometimes goes smoothly, sometimes it’s faster than we imagine possible. Then there are stretches where it feels like we’re clambering around in the dark.

For instance, I was once asked to write a WAP application (think super early mobile apps before smart phones existed). I had absolutely no idea what I was doing and I was mostly left alone on the project. I started by drawing some screens, took a deep breath, and started building. It was really tough going, but so many lessons have stuck with me from that experience. My skills at breaking down challenges and approaching them bit by bit really improved. I became comfortable throwing away code because the first code I wrote was atrocious. Plus, the project was eventually canceled, which was entirely the right business decision. Through that, I learned about evaluating tradeoffs in terms of business value—my time was better spent on higher priority projects.

In my current adventure, nearly 20 years later, I’m once again writing a mobile app and applying all of those lessons. Picking up languages and frameworks that I haven’t used before is far less daunting. Ensuring that I’m working on the most important thing is a constant recalibration, but one that is comfortable now. Working through stumbling blocks one at a time and having patterns for getting through them is second nature.

Just like learning isn’t linear, neither are careers. Your path will be your own. What you are doing today may or may not be what you’re doing in ten years. You might go into any number of other areas in software, or stay the course as a developer. It’s your life and all those choices are equally valid. One of my former colleagues quit to make hand-built microphones; another makes goat cheese in the Catalan Pyrenees. My personal philosophy is that at each opportunity to make a career decision, you should pick the direction that interests you most. Just like you learn faster when you are interested in your subject, you will ship better software (or make better cheese) when you are interested in your job.

There’s much more I’d love to tell you, but this letter is growing long. I’ll add some concise tidbits before I end.

  • You belong here. Try not to doubt that.
  • Get really good at debugging. It’s a skill and you will need it.
  • If you don’t respect your boss, or if they don’t respect you back, go find a new one.
  • Learning is part of your job. Make time for it.
  • Don’t be afraid to put your code in production.
  • Be a good team member. You will accomplish more and learn faster.
  • Ask lots of questions. Someone else probably wants to hear the answer.
  • And finally, have fun! You’ve got this!

I wish you all the luck in the world!

Sincerely,
Rebecca Campbell

Rebecca Campbell said “hello, world” to software development more than 20 years ago. She started as a developer before moving into team management and then senior leadership, and is currently working on co-founding a startup. She blogs sporadically at nerdygirl.com.

You Should Play (A Lot) More

This is a guest blog post from Zach Turner. Enjoy.

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

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.

Never stop learning

Dear new developer,

I was at a lunch a few weeks ago and asked some senior engineers and managers what advice they’d give to a new developer. One said: “never stop learning”. I thought this was a perceptive answer and wanted to expand on it. I learn something new every day. I’m going to talk about how to learn and then why people stop learning.

First, how to learn. I think the short answer is “Google”. The internet is an amazing place.

The longer answer is:

  • Think about why you want to learn. Is it for fun? To find a better job? To be better at the job you are at now? A side project that you are interested in? Scratching your own itch with a solution? Because you want to make the world a better place? Having a firm “why” will encourage you when things are difficult.
  • Determine what you want to learn. From the why comes the what. Is it a business  domain? A particular technology? A framework? A certain mindset?
  • Consider how you want to learn it. After what and why comes the how. Do you learn best through videos? Reading? Code tutorials? Blogging? A realistic side project? Reading others’ code? Try each of these if you haven’t and see what gets you excited and what seems to cause knowledge to stick.
  • Execute. That one little word is hard to do. But you need to find the time and the willpower to take the why, what and how and actually do it. As some say, it’s easy to write and hard to do. Start. And when you fail to make as much progress as you’d like, think about the why.

Why do people stop learning? I think there can be any number of reasons:

  • Bored: they simply aren’t interested in learning.
  • Frustrated/blocked: they can’t learn what they want to because of other constraints.
  • Tired: too much else going on and they need their energy for other things.
  • Comfortable: they know what they need to know and are “punching the clock”.
  • Shifting priorities: other things in their life have taken precedence.

All of these make sense. And it’s important to realize that you have a job to live your life, you don’t live your life to succeed at your job.

But, if you are not interested in learning new things, pretty soon technology will pass you by. You can still make a great living, but opportunities will get fewer and fewer, and you may need to shift companies or locations, or give up salary. There are definitely people still writing COBOL, but every year fewer companies need it. There may be people still writing java applets, but I can’t think of any companies that need that particular technology.

Another thing to note is that sometimes a shift in perspective, whether a new job or a new way of looking at your current job, can remove some of the obstacles that prevent you from learning.

So, figure out how you want to learn, and never stop doing it.

Sincerely,

Dan

It is never too late to start learning how to code

This is a guest post from Jenna Quindica. Enjoy.

Dear New Developer,

I didn’t learn how to program until I was 18; in fact, I didn’t know about computer science the concept until I was 18. It is never too late to start learning how to code.

In the beginning I struggled the most with navigating acronyms, words, and phrases I’d never heard of. I vaguely knew what a server was, but I didn’t know what a command line was, let alone what you do with one. File extensions that weren’t Microsoft Word, Excel, or PowerPoint confused me. The closest I got to computer science as a kid was clearing my Chrome browser history. My Neopets password was five alpha characters, and I was devastated when my account got hacked.

I didn’t start to enjoy programming until I knew how my piece fit into the rest of the picture. Find a friend who can teach you the vocabulary so that you can better understand the ecosystem.

Warmly,
Jenna

Jenna Quindica is a software engineer at First Round, a seed-stage venture capital firm. She dropped out of her computer science major at Cornell University to work at four early-stage startups. She lives in the San Francisco Bay Area.

Develop empathy

Dear new developer,

Right now you’re probably a bit frustrated and confused. You’re learning a lot of things and you don’t really understand everything. Sometimes things click and it all makes sense, other times you’re confused and staring at what feels like a brick wall. Perhaps you just want to make things work and they won’t.

Good.

I say that not because I’m a sadist or dislike you. I say that because I hope you’ll remember the frustration you are experiencing right now. I think that will make you a better developer.

Why?

Because that is the state of 99% of your users. Whether they are a business employee or a person trying to use your app for personal reasons. They are just trying to finish a task and get on with their life. The software you are writing is the tool they are using to do that.

  • They don’t care about elegance of code.
  • They don’t care how much you love to develop.
  • They don’t care if you are learning and growing.

They just want to finish their job, complete their task, do their thing.

And, honestly, the tools we provide are frustrating. They’re buggy. They’re slow. The fact that they are amazing compared to what we could create a few years ago and that they are better than the alternative is beside the point.

I don’t write this to cause despair, new developer. Progress is being made. But it’s made one person at a time. Each person has to act with empathy toward their frustrated users. Understand them. Care about them.

And if you can remember the frustration you are currently encountering, perhaps you’ll have just a bit more empathy toward your end user, who is just trying to use your work product to get something done.

Sincerely,

Dan

How to Develop Expert Intuition

This is a guest post from Kim Schlesinger. Enjoy.

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 in this blog post.)

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.

Kahneman says that the ingredients for this kind of expertise are

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 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, but being intentional with how your craft 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 through code reviews, you can get feedback on your technical and non-technical performance through regular 1:1s with your manager, and you can reflect and improve on your performance by keeping an end of the day journal where 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 6 or so months to get a grasp of cloud computing in AWS and Google Cloud Platform, Docker, Kubernetes, and the wide variety Continuous Integration/Continuous Deployment platforms.

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 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

Kim Schlesinger is a Site Reliability Engineer at Fairwinds Ops. Prior to Fairwinds, she co-founded 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 2-day conference for developers, designers, strategists and tech leaders.

Learn SQL with sqlite

Dear new developer,

I wrote a post about learning SQL a while back. I posted the link in Lobste.rs, an online community, which generated some interesting comments.

One of them was that sqlite was a better way to learn SQL than using PostgreSQL or MySQL. This is due to the fact that there are some administrative tasks that could lead to possible confusion with those more powerful SQL databases.

I downloaded sqlite and agree that it is a super simple, low risk way for new developers to learn SQL. It’s a single zip file and you can create tables and run through tutorials without having to worry about what port something is listening on.

The flip side is it won’t be as applicable to your on the job experience. There are definitely people out there building wonderful solutions with sqlite. But I think for most typical new developers, an experience with a client server relational database like PostgreSQL or MySQL are more likely.

Here’s the download link, you most likely want the tools precompiled binary. And here’s a quickstart guide.

Sincerely,

Dan