This is a guest post from Morgan Whaley, lightly edited. Enjoy.
Dear new developer,
Honestly my #1 piece of career or technical advice to new developers is:
Be adaptable and authentic.
I don’t think there is any one magic bullet to helping someone “break into” a job, or business, or new city. Humans are all different and the beauty of diversity in industry and environments is when everyone truly brings themselves and overrides the homogenization that we accuse modern cities and tech of becoming.
If something isn’t working, there’s “no harm, no foul” in changing approaches, or taking a break, or simply admitting something isn’t working.
I see a lot of people who treat that first job like it’s a task they gotta beat into submission and they tie so much self-worth to it. Which is completely understandable… but the more you resist a situation and don’t remain open to possibilities, the more you are going to run into brick walls.
PS Also, LEAVE YOUR HOUSE AND GO TALK TO PEOPLE FACE TO FACE OH MY GOD PLEASE IT’LL BE OK.
Morgan Whaley is a Senior Prototype Architect at Charter Communications.
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.
Dear new developer,
When I was newer to development, I thought that conference speakers were experts in their area, harbored no doubts, and that they knew exactly what they were doing. Speaking about technology seemed scary (until it wasn’t).
I enjoyed this post, “Confessions of a Conference Speaker”, pulling back the veil on the experience of a prolific tech conference speaker–20 talks in 2019. (She also has a post about being a conference attendee.)
I particularly enjoyed this section, titled “The Audience is Rooting for You”:
People come to conferences and attend your talk with the hope of getting value for their time. But that’s what is important to remember. They WANT to have chosen a good talk. They WANT you to succeed!
Being a speaker can be nervewracking for any number of reasons. There is so much prep that goes into it. Not every talk will go perfectly. But it helps to remember that the audience is rooting for you. This is especially true with those live coding mistakes. They’ll enjoy helping out 🙂
And the tips about a tech check and adding your author info on every slide were spot on based on my limited experience.
I can’t recommend public speaking enough for a a way to level up your skills. It can be terrifying, but you’ll learn:
- how to dig into a topic
- how to present something in a coherent fashion
- the confidence of knowing that you (likely) know more than anyone else in the room on this topic
- the value of connecting to your peers
If you are considering doing a talk, I’d suggest starting at a meetup or a lightning talk at a conference. Read the whole post to get Laurie’s inside view.
Dear new developer,
A few years ago I was job hunting (during a hot job market and with almost two decades of experience) and had a lot of people turn me down or say I wasn’t a good fit. Sometimes it was for coding ability, sometimes it was for familiarity with various systems, sometimes it was because I wanted too much money. I have turned down or left jobs for a variety of reasons, including money, demands on my time, or even just a bad feeling.
What I want to drive home, dear new developer, is that a job needs to fit both sides. The employer and the employee should both feel like they are getting a good deal.
The honest truth is that this means that there are some jobs that you could perform well at that the employer doesn’t know, believe or trust that you can. That can be a blow when you are looking for work. I’ve been there, hungry for anything that will help pay the bills. But you have to have faith. And keep looking. There are lots of developer jobs out there, at big companies and small companies, product companies and consulting companies, software companies and companies that don’t know they are software companies yet. And often, especially as a new developer, you can get hired for your potential.
I’ve also been in jobs where I contorted myself, either a little or a lot, because I thought that was what was needed. I’m all for taking one for the team for a while and doing an unpleasant task or job. But if I have to do it for months and years then that is the wrong job for me.
You have to fit the job, and the job has to fit you.
Dear new developer,
I thought this article nicely laid out three principles to guide a developer’s career.
- follow your taste
- find community
- take risks
Each of these really resonated for me. The first because the wide world of software can lead to analysis paralysis, so you should really have some way of deciding what you want to work on. When you are starting out you don’t have too many ways of doing so. Taste is better than random choice.
I’ve already written about the benefits of finding community (online or offline) and how it can help you grow.
Risk is an area I haven’t covered much on this blog, but in my own career I have overvalued stability. If I had it all to do over again, I’d take more risks, because I fall prey to overestimating the impact of failure on my life. (Of course, that’s easy for me to say looking back.) An example of that is that I waited until I was in my 30s to really commit to a startup; I had the skills to do so earlier, when it would have been easier financially, but I was too afraid to give up the stability and money of the consulting I was doing.
Here’s an excerpt from the article about following your tastes:
The default path is to follow what’s popular or prestigious. That can lead to a bunch of problems: What’s prestigious is already highly competitive. When you compete with smart people in a game that has established rules, just keeping up will take most of your time. That leaves little time to explore what interests you. When you don’t explore what interests you, you won’t understand things as deeply, and that leaves you with an undifferentiated skillset.
The whole thing is worth reading.
Dear new developer,
I recently learned a new skill. And I wasn’t good at it. (The skill, if you must know, was writing with a certain tone for a corporate blog. But the lessons below apply for any skill.)
I don’t like being “not good”, aka bad, at something. Especially since it was adjacent to an activity I’ve been doing for years, which is blogging.
I would get feedback on how to improve this or that. I understood the feedback, it made sense, but the overall feeling I had was of failure. I felt shame because this was something I thought I knew. That honestly pissed me off. But after the shame passed, I acknowledged that the comments were correct, that I wasn’t producing what I should.
It’s important to acknowledge that it’s OK to fail (I’ve covered that before) and that it’s OK to be bummed about it. We’re all human and the emotions are part of it.
I had a couple of choices. I could keep trying and make improvements over time. Or I could decide that, hey, maybe this wasn’t the right task for me to do.
The question is, how do you decide? I think there are a couple of ways to think about this choice:
- how core is this skill to your job?
- how core is this skill to the company?
- how long do you think it’ll take to get good?
- do you enjoy it? do you want to be good at it?
- is there another way to solve the problem other than you doing something you’re not good at?
- is there someone at your company who can help teach this to you?
Note that it isn’t just your opinion on these that matter. You also want to make sure you get your boss’s opinion, on each of these questions. The discussion is important and will determine how and where to invest your time.
If you despair because you’re bad at something, don’t just beat your head against the wall. Step back and be strategic about your efforts.
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.
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.