Your network increases optionality

This is a guest post from Karl Hughes. Enjoy.

Dear new developer,

I was in your shoes in 2011. I was finishing up a degree in mechanical engineering that I would never use and looking for a way to join a startup as a software developer.

Maybe it was the entrepreneur in me, and maybe it was just naivety, but instead of applying for jobs, I decided to start emailing interesting companies instead. I made a list of technology startups in the education industry and emailed each of them my pitch.

Two of them got back to me and one (Uloop) had an office three hours away in Nashville. I drove to meet their CEO and after a few conversations, they brought me on as a freelancer. When I graduated a few months later, they offered me a full-time role managing their blog and writing custom WordPress plugins.

Since then, I’ve worked at three different edtech startups and never once had a formal “job interview.” Every company I’ve worked for has hired me because I met someone there and stayed in touch for months. When a job opened up, they reached out to me to see if I was interested.

My first job hunt showed me that your strength as a software developer is not in your resume, your knowledge of algorithms, your ability to keep up with the hottest frameworks, or even your problem-solving skills. The most powerful tool you have is your network.

The Employer’s Perspective

As a job-seeker, you know that looking for a job is scary, but from an employer’s perspective, hiring is scary too.

After sitting in the hiring manager’s seat several times in the past few years, I can tell you that I’m as scared of hiring the wrong person as you are of screwing up the job interview. If I make a bad hire, I look bad to my boss, and my team’s productivity will suffer. Having to fire someone kills morale and hurts the manager’s reputation, so nobody wants to do it.

This fear is why managers look for people in their networks or work with recruiters. The very last place employers look for applicants is the cold resume bin.

How I Built My Network

If you want to avoid the black hole of submitting your resume online, you need to build a network. I don’t know you well enough to give you a perfect formula for your situation, so I’ll just tell you how I built my network. I hope some of these ideas resonate.

First, I started as a freelancer before I ever had a “real” job as a programmer. Most people don’t recommend this approach for new developers, but it forced me to learn to “sell” myself really well. When I started with Uloop, I often had no idea how to accomplish a task, but I bet that I could learn it before they discovered I was making it up.

After getting that first job, I started attending meetups and conferences regularly. Uloop was a small company, so there wasn’t much opportunity to network within the organization, but I had moved to Chicago, where there were plenty of programming meetups and tech events to attend.

I tried meeting people at these events, but it was hard. I’m not that outgoing, so instead, I would email the event’s speaker or organizer afterward and invite them to a one-on-one coffee or lunch. Some of the people I met like this are among my closest mentors and friends today.

As I attended more meetups and got to know speakers and leaders, people started inviting me to give back. I was little more than a junior developer at the time, but I was asked to speak at bootcamps, meetups, and even a couple of small conferences because of my network.

Naturally, I was nervous the first few times I got up in front of a group to share my experience. I knew there were people in the crowd with decades of experience on me, and I expected them to stand up and call me out if I made any mistakes. I found that practice and gradually increasing the stakes helped me. By trying a talk out at a local meetup and slowly working up to larger audiences at a conference, I gained confidence over time.

Giving a talk at a meetup or conference is a lot of work, and you don’t typically get paid for it. That said, I knew how helpful it was hearing developers who were more experienced than me back when I was first learning to code, so I have always enjoyed the opportunity to give back.

One side effect of speaking is that you get even more opportunities to increase your network. At some point, I switched from being the one asking speakers to meet with me to the one that attendees were asking to speak with. I always enjoy these interactions with new developers, and the opportunity to encourage or help others is my primary motivation for speaking and writing this letter.

Keeping in Touch

Everyone who talks about networking tells you to go out and meet more people, but that’s worthless if you don’t keep in touch with anyone. As I started to meet more people in Chicago, I realized that I needed to come up with a way to have more encounters with each of them.

“It takes on average about 3 encounters — and by that I mean intentional rather than passing interactions where you’ve gotten together primarily to just hang out — to really see if there’s potential for a relationship with someone.” – Brett McKay

The first step was to start a spreadsheet of people I wanted to keep up with. Most of them were more experienced than me, but many were peers or newer developers I “clicked” with or found interesting.

Next, I made a reminder to reach out to 1-2 people on the list every week. I’d ask how they were doing and see if they wanted to get lunch or coffee sometime. I tried to find organic reasons to connect (birthdays, an article related to their industry, etc.) and ask them questions about their lives. One of the easiest ways to make someone like you is to get them talking about something they like. People love talking about themselves.

While this sounds calculated, I do genuinely enjoy these conversations. We’re all busy, but having a system like this ensures that I don’t forget to maintain my network. If I ever feel like I’m no longer getting along with someone, I remove them from my list and no harm is done.

The reason most people don’t do this is that it takes a lot of time. I still spend 4-6 hours per week keeping in touch with or expanding my network. It may seem like a lot, but the investment has paid dividends and afforded me many interesting conversations and relationships along the way. This strategy of intentionally staying in touch with people has led to friendships, co-workers, job offers, and clients.

Make It Yours

No career advice will work for everyone.

I didn’t write this letter to give you a formula for networking, but rather to let you know that unconventional approaches can work. My network has been an invaluable asset, but luck and privilege played a huge part too.

If I hadn’t been able to drive three hours to take a meeting with my future boss, would he have hired me? If I needed to be home after work to help care for a family member, would I have been able to network at Meetups? If I weren’t a white male in an industry dominated by white males, would people have taken the time to meet with me?

I don’t know.

I have no idea what your career path will look like, but I hope my story gives you the courage to build a path that works for you.

Signed,
Karl

Karl is a former CTO and freelance writer. He’s currently the founder of Draft.dev where he helps companies create content that reaches software developers.

Seek feedback loops

Dear new developer,

Feedback loops are so important. (If you’re not sure what that is, I’d recommend “Thinking in Systems”.)

These loops help systems improve. If you don’t have feedback, you’ll improve more slowly, in my experience. Why? Because you won’t know what you are doing that is good and what is garbage. It’s really hard to evaluate that kind of stuff yourself. You can do it, it just takes time and perspective.

And of course, you want to do more of what is good. Here are some kinds of feedback loops which have helped me.

tests
one to ones
public writing
being a contractor

Automated tests are a really tight feedback loop. You can make changes to code and know if you’ve blown things up. (Type systems are another tight feedback loop preferred by some.) This is helpful in many situations, including when you are debugging a problem.

One to ones are a great way to gather feedback from your manager on problems, challenges and situations that you have faced. By doing it in a one to one (rather than a one off meeting), you’ll build context and history around these. After all, the tenth time you bring up the fact you find front-end development challenging indicates that this is a pattern, and you should evolve yourself or the position to help with the challenge. When you have your meeting, make sure you ask for feedback explicitly. When you get it, avoid being defensive. If you make it hard to get feedback, you’ll get less.

Public writing, especially a blog, is a great way to get feedback. You’ll be able to put your thoughts out in public. This can be scary and frustrating; some communities are more gentle about feedback than others. But the act of writing forces you to make the implicit explicit. And sharing that knowledge is a great way to get feedback. (Even a lack of response is feedback; what you were writing didn’t resonated with the audience you shared it with.)

I think everyone should try being a contractor. First it makes you appreciative of everyone else in a business, because when you are contracting, you often have to take on roles outside of development (sales, accounting, marketing). But for the purposes of this post, contracting is a great way to get feedback from the market. You’ll learn about which skills are in demand and what organizations will pay for those skills. Of course, you can find this out as an employee, but if you are a contractor, especially a short term one, you’ll be interacting with possible hiring managers much more often than as an employee. And the feedback loop is brutal and blunt: do they hire you or not.

Feedback loops are a key way to find out whether what you are doing is working or not. Seek them out.

Sincerely,

Dan

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

A letter to myself as a fresh software engineer

This is a guest post from Luca Florio, lightly edited. Enjoy.

Dear Self,

You just graduated and you are ready to start your career in the IT field. I cannot spoil anything, but I assure you it will be an interesting ride. I’m writing you this letter because I want to give you some advice that will help you be a better professional. Nothing you won’t learn by yourself in the next few years, but it is something that I wish someone had told me when I started my career. They are not ordered by any means and are all equally important.

Run a marathon, not a sprint.

The road to becoming a good software engineer is a long one. Don’t rush on stuff, and don’t give up just because you are not getting an easy and fast win. Take your time to learn and become good in the topics you are interested in. Remember that this is a marathon, not a sprint.

Be humble, not stupid.

It is good — sorry, it is fundamental — to be humble. There is always something to learn from others, even when you are an experienced professional. But this doesn’t mean that everyone is better than you. You have to respect yourself and your skills. When you don’t respect yourself you become stupid, not humble.

Compare with yourself, not others.

There is no point in comparing yourself with others. There will always be someone better than you in your job. And there will always be someone better than the one that is better than you. And there will… ok, you got the point. Just do your best. If you think someone is a better engineer than you are, learn from him/her. Keep doing your best, and eventually, you will be a reference for someone else.

Respect people, not titles.

During your career, you will work with exceptional professional. Most important, you will meet exceptional human beings. Respect people for who they are, not for the title they have. If “foo” is “Principal Senior Lead Engineering Chief Architect” doesn’t mean that he deserves more respect than “bar” that is a junior software developer.

Choose the challenge, not comfort.

The road will be full of crossroads. There may be multiple choices, but everything boils down to a choice between your comfort zone, or go outside your comfort zone. There may be a moment in your life — hopefully after decades of work — when you will feel the need to cool down a bit because you will be satisfied with what you achieved. Until that moment, try to go out of your comfort zone. It will make you a better professional and you will feel more satisfied with your career. Remember that the best things often happen outside the comfort zone.

Jump on the whiteboard, not on the keyboard.

When you have to design a new feature or a new system, don’t jump on the keyboard to start coding. The “muscle” you have to train and use as an engineer is your brain, not your fingers. Always think before acting. For this reason, jump on the whiteboard instead of the keyboard, and start thinking of what you should implement. Better if you have a sparring partner to challenge your thoughts. Oh, when I say “the whiteboard” I mean “every object that can help you think”, be it pen and paper, a notebook application, draw.io, etc.

Deliver value, not code.

Please don’t be affected by the NIH syndrome. There is no point in reinventing the wheel. Avoid wasting time in something that is already out there. If you can achieve your goal simply glueing together some tools, just do it. What you should deliver as a software engineer is value to your business, not lines of code.

Choose life, not work.

In the IT field, it is easy to focus too much on work. After all, for most of us, it is not just a job, it is passion. Remember that work is important, but life is more. Live a meaningful and rich life. Play sports, read books, find hobbies, travel and see the beautiful world we are living in. Hangout with friends, find a partner for your life and give to your partner all the love, attention, and support that you can. You’ll be surprised how much having a rich life will improve you as a professional.

That’s all I can tell you right now. I still have a lot to learn.

One last thing: enjoy the ride! 🚀

With love,

(a more experienced) You.

Previously published at florio.dev.

Luca Florio is a Software Engineer working remotely for Pleo, a Danish startup. He loves to study new things and share what he learns in his blog.

How to go through a layoff

Dear new developer,

At some point in your career, you might get laid off. This is different than being fired for performance reasons (which might happen too, unfortunately). First off, I am not a lawyer, so this is based on experience, reading and research, not a law degree.

Please don’t take this as legal advice or anything other than an informative blog post.

So, you get called in for the meeting. Your boss is there. Likely someone from HR is there. They tell you the news that the company has decided to part ways with you.

Your heart sinks. You get a big fat packet of paper. The HR person runs through it quickly and asks if you have any questions. You feel a bit dazed.

Take a deep breath. Realize that no matter how crushing this feels, two things are true:

this isn’t personal.
you’ll get through this.

Ask any questions you have. Some important questions:

when do you have to sign this packet of documents by
is there a severance, and if so, how much
what about other things that were yours (401k, FSA, HSA)
how to say goodbye to your teammates
what about other things that are the company’s (computer, books, equipment, etc)
who at the company you should contact if you have other questions

Don’t be unprofessional. Don’t get mad.

Don’t try to get your job back (it’s gone, sorry!). Don’t agree to anything other than reviewing the paperwork.

Make sure they have a non work email for you so they can send you additional docs if needed.

By the way, if they have their act together, you won’t have access to your work accounts after the meeting, for better or worse.

You can ask why you are being let go. Don’t be surprised if you don’t get many details.

Email or LinkedIn are good options for saying goodbye. Write a quick note to your former co-workers stating that you enjoyed working with them. You can express regret at leaving, but there’s no sense in badmouthing anyone. You never know if you’ll end up working with these folks again.

After the meeting, take some notes on what happened during the meeting. Use your own computer or a notebook. This will help make sure you understood everything that happened. If you want, add some details about anything leading up to the layoff (some things are more obvious warning signs in retrospect, and you want to remember them in the future).

Before you sign anything, it’s always a good idea to run any agreement by an employment lawyer. Yes, they cost a lot of money ($X00/hr) but they’ve seen these kind of contracts before and are legally obligated to do right by you–unlike the company’s lawyers who wrote up the agreements, who are obligated to look out for the company. At this point it’s “just business”, and you want to protect yourself. Ask the lawyer for their advice (“does this seem reasonable, are there other clauses I should ask for”), but make clear your budget and timeline. (If you don’t know a lawyer, ask for a referral from a friend.) There may be some back and forth with the company over the documents.

After the lawyer has looked any agreements and you’ve had some time to think, you can sign the agreement. Or you don’t, based on their advice and your feelings.

After that take a bit of time to grieve, if you can. Even if the company or job wasn’t the perfect fit for you, it hurts to part ways.

Then, roll up your sleeves and start looking for a new opportunity. Is it time to try contracting? Maybe something else that is risky? Or to reach out to your network and see what is available?

A layoff feels like a defeat. But you’ll get through it.

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:

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

The best career advice I’ve ever gotten

This is a guest blog post, lightly edited, from Josh Doody. Enjoy.

Dear new developer,

Let’s talk about jobs.

My first job

I was 25, and I wanted to move my career along as quickly as possible. I had my first real job, and had gotten three raises and a promotion in only two and a half years, nudging my salary up 12% from when I started. I was feeling pretty good.

Then two things happened that changed my career’s trajectory. First, my boss told me that striving for big raises and promotions would get me nowhere. “The way things work around here,” he said, “is you might get a big raise one year, or even two raises, but they’ll eventually work out so that you’re right back at the average. It’s hard to get ahead or fall behind.” He meant that I might be on top now, but eventually I’d regress to the mean. My boss had been working at the company for 30 years, so he knew what he was talking about. Ouch.

Second, I had been begging for a new challenge and just hadn’t gotten one. I had been looking for ways to stay interested, but got more and more bored, so I asked my boss for a new challenge. He eventually offered me a new opportunity: the same work I had been doing, but in a crummier location. I asked if we could keep looking.

A couple of months later, my boss came to me with yet another opportunity: I would move to a different building and redraw schematics for a 20-year-old piece of test equipment. I could hardly believe it, but he’d actually found a worse position than the one I’d already turned down.

But he made it clear that I couldn’t keep saying no to these opportunities—I was being too picky, and it was making both him and me look bad—so I reluctantly accepted the position.

I moved from a building where I had tons of friends and a 10-minute commute to a building where I had no friends and a 40-minute commute. The clock was ticking on my time at that first job.

Looking for something new

I started looking for a new job for two reasons: first, I needed to get out of there; but second, I wanted to know if I was over-valuing my abilities. I was young but self-aware enough to realize that one very plausible explanation for my frustration was that I just wasn’t very good at what I was doing. Maybe my boss was in the uncomfortable position of having a really ambitious, but really ineffective employee on his hands. Maybe he had done everything he could to pacify me without putting me on an important project that I would just screw up.

Around this time, a friend reached out asking if I knew any web developers looking for work. I told him that I did know someone…me! I had a little bit of web development experience and after we talked, he suggested I might be a good fit for his startup’s client services team. I interviewed with the company’s CCO and he offered me a job as a Project Manager. I had also been interviewing for a managerial position in a different city and, although I didn’t get that job, those two opportunities reassured me that I was a valuable enough employee to take seriously. I happily took the Project Manager job at the start-up.

Before I could start my new job, I had to wrap things up at my old job. Ironically, my manager on my temporary project (redrawing old schematics) had been the best boss I’d worked for my whole time there. On one of my last days, as we were looking over some schematics, he gave me the best career advice I’d ever gotten:

Josh, your first job is where you get your first job. Your second job is where you get experience. Your third job is where you get paid.

My second job

My second job meant a career change from electrical engineering to project management. I took a small pay cut, but that was completely reasonable considering I had no client-facing experience. I went on to work there for five years, scratching and clawing my way to a slightly higher salary than I’d been making as an engineer.

Of course, the money wasn’t what I was after—I wanted experience, and I found it by pursuing unusual opportunities, including a “special project” that ended up being crushed after nine months and getting me laid off. But they soon hired me back to work in a different capacity, which again provided great experience for slightly less pay. This position marked my second pay cut since starting my career, and I was making exactly the same salary I’d made as a test engineer, five years earlier. But by then, I had amazing experience and was in a position to move nowhere but up.

After five years in my second job, I finished up my MBA, which I’d been pursuing on the weekends. I decided to quit and take some time off to travel, relax and recharge.

My third job

After my hiatus, an old colleague from the start-up reached out from a different company: “You looking for work?” I was, and my experience landed me my third job, where I would make almost 30% more money than I had been making when I quit the start-up eight months earlier. Just like my sage manager said, my third job was where I got paid.

I’m glad I heard that advice during my first job, because it allowed me keep putting in time when things got tough. I knew that getting paid was inevitable if I continued to do good work and gain experience. That advice allowed me to stop obsessing over raises and promotions and start focusing on trying new things and building my resume so that when I did encounter a lucrative opportunity, I would be ready.

Sincerely,

Josh

Previously published on JoshDoody.com

Josh Doody is a salary negotiation coach who helps experienced software developers negotiate job offers from big tech companies like Google and Amazon. He also wrote Fearless Salary Negotiation: A step-by-step guide to getting paid what you’re worth to help software developers navigate job interviews and salary discussions to earn more throughout their careers.

Be Adaptable and Authentic

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.

Morgan

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.

You have to fit the job

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.

Sincerely,

Dan

On mid-career challenges

Dear new developer,

I really liked this post on mid-career challenges. I know you’re new, but you’ll be mid-career before you know it!

I’m in a position right now where I have to figure out what comes next for me and how to navigate the challenges of getting there. I made it to senior engineer, I wrote a book, I spoke at a bunch of conferences, switched from ops to dev back to ops again — so now what? For some people, mid-career looks like figuring out what your next set of career goals might be, what you might want your next 10 years of work to look like. For others, it might mean changing careers — you might be in a position where you’re quite senior in terms of core skills such as communication, team dynamics, and project planning, but you came into tech from another field so your coding skills still have leveling up to do.

As you get your legs under you as a developer, it’s worth peering into the future so you can set yourself up for success. Setting goals is part of that. So is learning from other’s experiences.

As usual, the whole post is worth a read.

Sincerely,

Dan