But First, Don’t Do the Dishes

This is a guest post from Sonja Parsell. Enjoy.

Dear Developer,

Don’t misinterpret a small distraction, or even a big disaster, as a “sign” that coding isn’t for you.

There were definitely times in my journey when a break in learning was completely justified, but by no means should I have seen it as a reason to quit, or that I was missing the message that I didn’t have what it takes to be a developer.

Thanks to a lot of personal reflection, some low-tech research about my habits, behaviors and values, and not a small amount of tough love, I am happy with my progress now, even though it’s taken years to get here.

Maybe you’re struggling with something similar?

Don’t ~~sweat~~ DO the small stuff.

No outside factor is going to make you more productive, and if you need a certain atmosphere to be at your best, you’re not truly in control of yourself.
Rachel Hollis

I used to feel like the house had to be tidy before my mind was clear to sit down to learn/code. If I couldn’t get those tasks done, how would I ever have time to hold down a software engineering job?

My habit of clearing up the breakfast dishes, tidying up after the whirlwind of getting kids off to school, and letting the “silent do-do list” (totally worth a Google) shout at me was definitely keeping me from maximizing the best time I had to learn to code. I knew if I didn’t squeeze some coding practice in by 10:00 AM, it was likely not going to happen that day.

Those chores were a waste of my best hours. I learned to walk away from the mess in the kitchen (it was hard at first) and I now spend my most productive hours on my most important goal: becoming a software engineer.

Because really, there will always be dishes and laundry. I really didn’t mean to give them priority.

Never enough time.

You can’t see the silver lining through victim goggles.
Jen Sincero

I used to think I would never have enough time to learn enough to get hired. Who was going to employ me as a career-changer over 40?

Running is my go-to form of exercise because it’s one of the only things in life I get “enough” of in a short amount of time. At some point, I am tired and I have to stop. That feeling rarely comes when I’m writing code.

As a SAHP (stay at home parent) for the last eight years, my time hardly feels like it’s my own. But everyone has the same 24 hours in a day, right? How could I feel so unproductive?

To solve this, I started with a basic Excel spreadsheet by listing all the things I wanted to do, or were my responsibility (household tasks, volunteering, hobbies, learning objectives, social commitments, family obligations, after school activities, etc.). It seemed endless. No wonder I wasn’t actually doing any of it consistently or well!

After keeping track for a few weeks of what I actually participated in each day, the results were eye-opening. I now had a map of how I spent my time and, most importantly, where I could save it.

The four biggest changes I made to my days were:

Saying “No.” or “Not now, maybe later.” to anything that would interfere with my best coding hours: socializing, volunteering and doctors appointments were strictly scheduled for late afternoons or weekends only.
Waking up at 5:00 AM to have a few quiet hours to myself. This was transformative in how I felt about my progress (by the time I ate breakfast, I had already coded for two hours!) and how the day progressed.
Giving up a few things. I put a few hobbies on hold, graciously backed out of friendships and groups that didn’t make me happy, and even taught my kids to make their own breakfast and pack their own lunch.
Finding what to learn, when. I lined up coding podcasts for meal prep time. I caught up on all my Slack groups while waiting for the kettle to boil. I quit social media for periods at a time (apart from Twitter – all tech related for me). This helped to keep me focused but not burned out from just sitting at a screen, trying to learn in a silo.

Because really, you have more time than you think you do. You can’t do everything, but you can do anything you set your mind to. Spend your time wisely.

“You want to make websites??”

The first stage of forming an ambition requires imagining yourself in a role that requires skill and that exists outside of the domestic sphere.
Anna Fels, “Necessary Dreams – Ambition in Women’s Changing Lives“

I used to think my family and friends didn’t understand what I was trying to do or even why. So why on earth did I think it was a good idea? I must be crazy.

My friends said things like “You want to do WHAT? You’re training at a bootcamp for a nuclear what?”. (True story.) And there were giggles, looks of confusion, and eventually, they would change the subject, still in the dark about my goal.

My wonderful spouse thought it was an interesting hobby, but wasn’t excited to make space for it if my studying schedule interfered with the division of household tasks.

Through an amazing “Moms in Tech” slack group, I found hundreds of women trying to do what I am. We were all struggling with the same imposter syndrome, were misunderstood by loved ones (at some point in our journeys), and were filled with self-doubt. I decided to enroll in my coding bootcamp on the heels of a meaningful discussion with these women over Slack. I’ll be eternally grateful for their input, and I’m determined to pay back the favor someday to anyone who needs a sounding board.

Because really, your family and friends may never understand what you are trying to do. That’s why the coding community is so critical to your success. Just jump in and find your people. I promise they are looking for someone just like you.

Make progress every day.

It’s not complicated, it’s just unfamiliar.
fellow software engineering bootcamp student to whom I am eternally grateful and wish I knew your name

I used to feel like a failure for not achieving the coding goals I made each day, even if they were SMART goals. If I can’t figure this out, how am I going to move on?

You might want to finish a small feature but when you’re a newbie coder, nothing is linear. First, you need to know what 1a, 1b, and 1c mean, with the right syntax, and know what the errors are telling you, before you can even get to B. That’s NORMAL and it can take a lot of time.

What helped:

Keeping a journal of what I worked on every day. It helps to see your progress in words. And it reminds you of what you learned. Recall is an important part of learning.
Realizing I had too many things going at once. As a newbie, you feel the pressure – excitement even – to learn all the things at the same time. It’s truly a discipline (and worthy of practicing) to be able to focus on one language, complete one tutorial, or to build one thing at a time.
Repeating a course or an exercise doesn’t mean you’re not learning the concept or syntax. I know I need to see it, read it, watch it and then write it – at least 3x – before it feels familiar.

Because really, you’re still successful if you make consistent progress, not specific goals.

Driving with the brakes on.

Be strict about your goal, but flexible in how you get there.
Rachel Hollis, Girl Stop Apologizing

I used to think that when I had to take weeks or even months off from coding to take care of myself or my family, it was the ultimate sign I should quit. What else could it possibly mean?

I’ve been learning through babies and children under foot, a trans-Atlantic move, a brain hemorrhage, recovering from a brain hemorrhage and vision impairment, and, just two weeks after I spent some serious money by enrolling in a bootcamp, the pandemic hit. All the time I had reserved to finish the program, became dedicated to more housekeeping and homeschooling than ever seemed possible.

But six months into 2020, I was still totally committed to, and absolutely in love with my studies and — guess what – I was finally convinced that this is what I should be doing.

Yes, it took a pandemic.

Because really, changing your life is SO HARD. You just have to work harder. And you can, you just might be lining up at the start more times than you originally thought.

If I belong here, you belong here.

Regret is the thing we should fear the most. Failure is an answer. Rejection is an answer. Regret is an eternal question you will never have the answer to.
Trevor Noah, Trevor Noah: Born a Crime

We are our own worst enemies and often close doors that aren’t ours to close. Only you know exactly why you started this coding journey, and that’s all that matters. Don’t let anything or anyone stop you.

Especially those dishes.

— Sonja

Sonja Parsell is nearly finished with her software engineering bootcamp. After 15 years on Wall Street working in various finance and operational roles, she’s beyond excited to pursue an engineering career in blockchain. You can read more about her story.

Be kind

Dear new developer,

Kindness is an unsung virtue for software development. I touched on it in this post on empathy, but wanted to emphasize it again.

Practice kindness. When I was young, I thought scoring points and being right were important. They are, but being kind and a good human is even more important.

Be kind to your teammates

They are working with you to try to solve problems. They bring different experiences and perspectives. Value those. Assume positive intent. Yes, there may be the occasional toxic person, but in my career the vast majority of my co-workers wanted to do good work and help our customers.

Be kind to them by listening to them, trying to understand and incorporate their perspectives, and honoring your commitments to them.

Be kind to your users

Making software is an excellent career for many reasons. One of the best parts of my career has been building tools that help others do their jobs or live their lives more easily. To do so requires understanding of their problems, empathy for their constraints, and a vision for how to improve both.

Be kind to them by listening to them, especially when they talk about their problems. Understand that what you do is magic.

(Think of a highly focused discipline that you aren’t familiar with. I’m not a car person, and I still think that the fact that you can turn a car and have the tires go different distances without impacting the overall vehicle speed is pretty magical. This is similar to what users think about developers.)

Use your powers for good.

Be kind to your friends and family

As much fun as coding is, don’t disappear into it entirely. Spend time with friends and family. Forge those bonds.

I promise you in five years you won’t remember the precise problem you were solving today, but the friendship and family bonds you foster will sustain you.

Be kind to them by spending time with them.

Oh, and when you do, don’t talk shop. That gets pretty boring pretty quick.

Be kind to yourself

I read another tweet about a developer being burnt out and quitting the industry recently. It made me sad, because I think I could write software until my 80s. Not full time, but man can it be fun. It can also be horrendous. The environment matters, but so does setting and enforcing boundaries. Make sure you do so.

Be kind to yourself by taking regular vacations, setting and clearly communicating boundaries, and celebrating your wins at least as much, if not more, than your failures.

If you wouldn’t say something to a close friend in the same situation, don’t say it to yourself.

In conclusion, be kind.

Sincerely,

Dan

Uncle Bob’s Ski School

This is a guest post from Dan Walkes. Enjoy.

Dear developer,

I was thinking this week about my Great Uncle, Bob Van Gerpen, who died of pancreatic cancer in 2011. Bob was my Grandma’s youngest brother and similar in age to my Dad. He was a big part of my parent’s life as they experienced the same transition I did, going from South Dakota farm kids to Colorado “city” dwellers in their 20s.

In the long list of Uncle Bob folklore, there’s a particular story which popped into my head this week which I’ve thought about relative to my professional career. It’s the story of Uncle Bob’s Ski School.

As a South Dakota to Colorado transplant, Uncle Bob often had family and friends from the plains who would visit the Rocky Mountains to try skiing, often for the first time. Uncle Bob was not one to turn down a social outing and would always enthusiastically offer to take them up the mountain.

The visit would include helping them with rental equipment, making sure they had the proper gear, recommending the best place to go, finding discount lift tickets, driving them to the mountain, and getting them on the lift. There’d be some discussion about how to “pie” your skis (point the tips together to make a pie shape and slowly slide down the mountain) and some basics about keeping knees bent and suggestions about balance.

The flatlander trainee would ride the ski lift up to the top of the 12,000 foot peak and turn around to see nothing but what looked like a sheer cliff toward the distant specs of people and cars in the parking lot below. As the “student” was contemplating their most recent life’s decisions, Uncle Bob would ski past them, wave, and tell them he’ll meet them at the bottom.

A few hours later, bruised and tired, the newly minted Colorado skier would find Uncle Bob in the lodge at the base of the mountain with an adult beverage in hand.

I don’t know the total list of Uncle Bob ski school graduates and unfortunately the full list is probably lost to history. I do know he would proudly mention both of my parents in the list of successful graduates. He also liked to say his wife, my Great Aunt, was his only failure. After meeting him at the base of the mountain she informed him in no uncertain terms this would be their first and last time skiing together. Borrowing one of his favorite expressions, “a guy could” assume the true number of his ski school failures may have actually been a bit more than one.

As an Engineer, getting outside your own head and describing how to do something you already know how to do can be incredibly difficult. I’m grateful for my somewhat limited experience thus far as an educator to work on this skill. I have a long way to go. One of the things I’ve found to be the most difficult to do in my professional career, both in roles of educator or manager, is to give my students, employees, and coworkers just enough tools to figure out what they need to do on their own. Sometimes I suspect this feels to them a bit like Uncle Bob’s Ski School. Some of them are like my Great Aunt, who are understandably frustrated and ready to bow out after the first trip down the mountain.

Since I’ve been so fortunate to work with a pool of talented, resourceful, and persistent Engineers, however, I find that most rise to the occasion. They are able to overcome my shortcomings in course material or documentation and in many cases learn more themselves in the process. Course material or project documentation is never perfect.

When faced with a deadline the choice is to not share course material until it’s more perfect, or share what you have with the hope it will be useful. I usually error on the side of the latter and I feel like it’s worked out well so far.

If you are a student in a course or an employee working on a new project I encourage you to look at something less than perfectly structured content as an exciting challenge and an opportunity to learn how to learn. I also encourage you to think about what was missing which would have improved your experience and let the originator know or, even better, propose the change to curriculum or documentation which would have helped you and will help others.

When you become an expert, think about how you can optimize your Ski School professional equivalent to strike the right balance of being “perfect enough” to get the trainee started on their journey while minimizing the number who are ready to walk away for good when they make it to the base of the mountain.

— Dan

This post was originally published on LinkedIn.

Dan Walkes is Vice President of Embedded Engineering at Sighthound.

Always be replacing yourself

Dear new developer,

I had a friend who brought me into a club. The specifics of the club don’t matter, but like most clubs, it had a variety of executive roles. Someone had to run the meeting, other people had to take notes, someone needed to keep track of the finances.

As I took on more responsibility in this club, my friend gave me a sage piece of advice: “always be replacing yourself”. You don’t want anything to be your particular special area of knowledge. You should always be trying to train your replacement.

I think this is good advice for a software developer as well. At any new job, you are learning tons of new things. This is doubly true when it is your first or second job.

But, eventually, there will be someone even newer on your team. Whether through churn (if the size of the eng team is relatively stable) or new hires (if you are on a rocket ship), in a year or so you won’t be the new kid on the block.

Obviously this is a discussion to have with your manager, but you should always be looking at ways to replace yourself. This will free you up to work on new tasks and learn new things.

Here are some ways to replace yourself.

Document all the things

Don’t rely on your memory. When you are performing a task for the second or third time, write down what you are doing and why. (If you only do a task once, this is not usually worthwhile.) Keep this under version control and share it widely. That way anyone can see what you are doing and suggest improvements and/or take it over if you are on vacation or doing a different task.

Offer to cross train

When you are working with someone else, you both gain knowledge. Whether this is a command line trick a different view of the world, or specific domain knowledge, working with someone on a task will help you both. This doesn’t need to be full pairing, it could be an impromptu design session or troubleshooting discussion.

Automate for the people

If you are doing a task and have time time, write a script or program to do all or part of this. Don’t let the perfect be the enemy of the done. If you can write a script to do 70% of the work in 10% of the time it would take to automate the entire task, write that script. This pairs well with documentation and is a living form of knowledge transfer.

Obliterate the task

Sometimes a task is always done because it has always been done. With your beginner’s eyes, you can ask “why”. Don’t be crotchety, but try to get to the root of the problem to be solved, rather than focusing on learning the solution. There may be other ways to resolve the issue. There may not. But by understanding the root of the solution, you’ll be better able to see if you can avoid doing it altogether. This isn’t strictly training your replacement, but it will be welcome and does make the organization more efficient.

Don’t be a precious holder of specialized knowledge. Share it widely, train your replacement and you’ll be on to something new.

Sincerely,

Dan

Think about your career risk budget

Dear new developer,

In certain areas of software operations, the concept of an error budget makes an appearance. An error budget is a way of tracking how often errors occur. When the budget is exceeded, you spend time and energy to decrease them.

Having a number like this is a good way to align different areas of the business with the reality that at a certain scale and complexity, issues will arise. When this happens, the question is always, should you spend time fixing the issue or working on new functionality? The error budget helps make the answer clearer. (There’s a lot more to this concept and the link above is worth digging into.)

In the same way, you have a career risk budget. You will work for approximately 40 years, give or take a decade. Each job and career move you make is important, because if you move jobs every three years (on average) you get only 14 different opportunities. These are complex decisions; how can you choose which job at any given time is the right fit? Here are three things I consider:

Goals

This is a very common one. Is this new job moving me toward my goals? Goals can differ for each person, but here are common questions I ask:

Is it the tech stack I want? (The older I get, the less this matters to me, but it still matters.)
Am I working in an interesting domain?
Is this the size of company I want?
Will I have opportunities to grow?
Will things like work life balance expectations and culture be in line with what I think I want or have enjoyed in the past?

These are all trying to get at an answer to the question: Can I see myself at this company for a while?

It’s always worth writing down your goals and seeing if the company can help you meet them. But it’s also tough to be really clear on goals a few years out sometimes. After all, if you’d asked me in 2016 if I wanted to work in DevRel, I’d have said “maybe??”. Another filter for considering a career move is comp.

Money

I love writing software. I do it for fun sometimes. But the fundamental employer employee relationship is through compensation. I give an employer my time, knowledge, experience and energy. They give me money.

So there’s nothing wrong with picking a job based on money. In fact, from my experience and the experience of others I’ve talked to and read about, switching jobs appears to be the best way to get solid salary raises, especially in the current market. Some of the numbers I’ve seen are eye popping, including double digit increases. You won’t get that at the same company, typically. (However, I did get some double digit raises early in my career, from 42k->55k at one company, so it isn’t out of the question.)

Make sure chasing a higher salary aligns with your career goals too. Funnily enough, jobs in software which are unpleasant, career limiting or otherwise less desirable often pay more (the free market at work). So when you see that junior engineer position using MUMPS which pays 10k more than other positions you’ve seen, find out why.

Money is important, but not the only thing to chase. There are risks to any job and it’s worth thinking about them.

Risk budget

Another approach to fold in is your risk budget. There are all kinds of risks, but you want to look at financial, emotional and career risks.

Is the company going to be able to pay you? Do they have a viable business model? Do you feel like buying a lottery ticket (equity) with your time?
How are you going to feel working at this company? A valued part of the team, or an expense to be managed (or, worse, minimized)?
Is this position, in terms of responsibility, technology, and growth opportunities, going to help or hinder your career?

You can’t, of course, quantify all of these precisely, but you can assign relative numbers to them. This can be helpful when comparing opportunities, either side by side or over time.

Risk budgets change as you age, as well. For example, your financial risk budget may decrease as you have more obligations. On the other hand, it may increase if you build up savings or have a cushion.

As I get older, the team I am a part of has become more important and the precise technology less important. But that’s me. You need to take some time and think about what matters to you.

Sometimes you have to take a job to have a job. I get that and have been in that position. But if you have the luxury to have some patience, consider the above three factors and don’t forget your risk budget.

Sincerely,

Dan

Why Developers Should Engage in Continuous Learning

This is a guest post from Jerrin Samuel. Enjoy.

Dear new developer,

Software development is a field that evolves quickly and constantly. These changes keep things exciting and interesting, but can also make you feel like you are falling behind all the time.

Engaging in continuous learning is one of the solutions you can look into to stay updated in your profession and avoid feeling left out.

Continuous learning refers to the process of learning new knowledge and skills on an ongoing basis.

This type of learning can come in various forms, including enrolling in formal programs, such as taking up technical training courses, attending seminars, and engaging in self-study. It can also be sponsored by the employer or take place within the company, or it can be personal.

Benefits of Actively Participating in Continuous Learning

Continuous learning provides professionals in the field of software development several benefits, which include:

Remaining relevant

Since software development is a constantly evolving field, you need to stay up-to-date with all the changes that come up.

Taking up development or IT courses allows you to keep up with the latest trends. Moreover, you can broaden your knowledge and skills, enabling you to adjust and function effectively in the dynamic world field of technology.

If you want to remain valuable in your organization, you have to learn new things constantly.

Boosting your profile

Learning constantly means you are continuously growing and improving.

This also means adding more skills to your CV and profiles on various recruitment and job posting sites. These additional highlights can make your profile stand out and catch the eye of more recruiters and employers.

The certificates you gain and the recommendations by your managers and colleagues will also make your profile more attractive.

Improving your employability

Professionals who are constantly learning and upgrading their skills create a higher market value for themselves.

This is because employees that always stay relevant are highly sought after in the job market. As a result, employers go another mile to hire or retain them.

Preparing for the unexpected

Continuous learning helps you acquire skills that can propel you towards achieving success not only in your current workplace, but also in other companies.

Since the economy can be erratic at times, you need to be prepared for the possibility that you may lose your job. Having broader, up-to-date skills can increase your chances of getting employed again as soon as possible.

Your broader range of skills can also give you the confidence you need to take on new job opportunities so that you can get employed faster.

Increasing your self-esteem

Learning new things gives you a feeling of accomplishment. This, in turn, enhances your confidence and belief in your capabilities.

As a result, you will also feel more ready and confident to take on challenges and new job roles and responsibilities.

This boost in confidence will also improve their emotional and mental health. What’s more, it will increase their productivity.

Enhancing your creativity and problem-solving capabilities

Joining software development courses, seminars, conferences, and other reskilling and upskilling programs allows you to learn from the trainer or facilitator and your fellow learners.

Because of this, you will be able to come across new perspectives, techniques, and strategies that can help you think outside the box.

Whether you come across a problem that requires innovative solutions or need to create something new that has never been done before, you can also use the knowledge you learned from others to meet these challenges.

Broadening your mind

Continuous learning allows you to expand your mind and perceptions, thereby helping you change your attitude.

The more you learn, the better you will be at seeing things from different perspectives.

Your open-mindedness can help you relate and communicate with people more effectively. Whether you want to broaden your professional network or social circle, your new outlook and attitude can set you on the right track.

Getting the Most Out of Continuous Learning

When engaging in continuous learning, consider trying out different strategies. Aside from taking formal in-classroom and online courses, seminars, and workshops, be open to joining employee and managerial training programs.

Participating in social learning opportunities, such as team meetings or discussions and collaborations, are also effective strategies for upskilling and reskilling.

Coaching, mentoring, and on-the-job training programs also count as social learning opportunities, and thus, will contribute to your personal and career growth.

Lastly, there is also nothing wrong with branching out if you are interested in other fields. If you have the opportunity, learn skills not related to software development but can still contribute to your personal and career growth.

A project management, business writing, or employee motivation training course are excellent options to add to your portfolio.

Learning should be a continuous process. Always include it in your goals to experience growth personally and in your career.

Sincerely,

Jerrin

Jerrin Samuel is the Executive Director at Regional Educational Institute (REI) in Abu Dhabi. Since 1995, REI has been at the forefront of education by delivering quality corporate training courses in the UAE, helping many businesses and organizations achieve greater productivity and higher customer satisfaction levels.

Take jobs that help you grow

This is a guest post from Adam Steel. Enjoy.

Dear New Developer,

Getting your first developer job can feel like a big accomplishment. And it is! It can feel so big and you can feel so relieved to have any job at all that you might start to develop your worldview around that one job. “This is how things are in the real world” you might tell yourself. “I’m lucky to be here,” you murmur. “Leaving too soon looks bad on your resume,” says an older friend.

This sort of thinking can be entrapping. I’m writing to show you a better way.

The spectrum of jobs and companies in tech is broad. To understand how the world is and what your options are you have to take a couple samples and grow, grow, grow! To that end, there are three “traps” I see developers get stuck in early in their career.

The first trap: Spending too long at your first job

In your first 3-4 years, it’s critical that you fuel your motivation and inspiration into learning and growing. It’s also a critical time for a steep increase in your salary. Too many companies fail to recognize that a junior developer’s abilities are growing far faster than their compensation and responsibilities. Or it’s recognized but the company cannot afford to promote or give a raise. It’s up to you to take the reins and move to a new job to find the new challenges and new salary that match where you are in your career. This is especially true for self taught and boot camp taught developers.

How long is too long? How long is enough?

“Enough” time as a junior can be surprisingly short, depending on how you learn. At 6 months it is reasonable to consider switching jobs if you are learning quickly. Not for all positions you’ll hold, but specifically for this first one. Juniors are paid less because they need to come up to speed on all the terminology, tooling and processes.

Once you don’t need hand holding to tackle moderately complex features, you will be far more attractive to other companies. Occasionally a company may recognize and reward your growth, but that is rare.

Stay longer only if you’re feeling significantly rewarded and challenged. Which brings me to…

The second trap: Not investing in learning

Building business software in teams requires a set of skills that are hard to acquire in the absence of customers and a team working to support them. This learning curve can only be tackled when you have these components. And the best way to move along the learning curve is to take a job that helps you learn faster!

What does a “learning” job look like?

“Learning” jobs tend to have similar characteristics. There are resources to learn from and the autonomy to work however suits you best. There is time built into the team’s cadence to allow for research, either organic time throughout your week or time specifically set aside.

Most importantly, there are lots of smart people who give you feedback and engage in discussions about the best way to do things. These people will focus on things like best practices, optimization and customer value. Often they argue! While the arguments might excite you or wear you down, they should feel overall productive and, at the end of the day, move the team toward its goals.

Think of a learning job like an additional career investment, beyond whatever you’ve already paid to learn before your first job. What you need is exposure to good ideas in the context of solving a business problem with an experienced team, and a good learning job gives you that. You may take a lower salary in the short term, but by expanding your knowledge your career will be more fulfilling long term.

What should I avoid?

The list of positions where learning is difficult is much longer than the list of “learning jobs”, but here are some examples:

Isolation: Working alone is the hardest career decision to come back from, but it’s especially destructive in your first job. If you aren’t challenged by the ideas of multiple people, your world becomes small. You also won’t have a chance to build your network.
Micromanagement: Good companies work to give their developers autonomy and space to do the right thing. If someone is managing the details of your daily life, you aren’t learning how to flex that autonomy muscle. For example, once I had a job where a senior manager stood over my shoulder and dictated what he wanted to see as I wrote code.
Lack of visibility: Do you get a chance to learn how the pieces fit together? Do you get a chance to fit them together? A narrow field of view restricts your ability to build a larger context. For example, are you only ever asked to fix specific bugs, or are you encouraged to think about the larger architecture while building new features?
Unsafe environment: If we don’t feel safe, we cannot learn well. Depending on the threat, there could also be much bigger concerns. Examples include, but are not limited to, yelling or harassment of any kind. Leave as quickly as you safely can.

The third trap: “Being glue”

“Being glue” is when your role is focused on filling gaps like coordinating between teams and keeping everyone organized, as opposed to actually writing software. Especially in smaller, more dysfunctional teams it can be a tempting role to fill. The team needs it, after all! It’s an important role for managers and higher level engineers to fill, but if you step into it too early it will stunt your learning curve and can leave you forever feeling like you are “behind” the rest of the team. It’s first (and best) described in this noidea blog post.

Once you are technically competent, and everyone knows it, consider taking on this work.

Finding a job that maximizes your growth

There’s no silver bullet for this problem. My best advice is to try to develop the ability to “sniff out” the kinds of companies you’re looking for. Did someone impressive speak at a meetup or write an inspiring blog post? Track down where they work. Job descriptions that are well written and articulate good values are promising. And if you end up in a job that you misjudged and find yourself stagnating, don’t feel guilty about quickly moving on.

Consultancies with great practices, like TestDouble, can be great accelerators for your learning. Changing projects more frequently results in a broader experience, but at the predictable cost of less experience with how your decisions in a codebase will age.

What does a “good” job description look like?

Writing a good job description is hard, but the best companies will put in the effort to do it right. Some attributes of good job descriptions include:

Reasonably correct English and readable formatting
A description of philosophies and values that align with yours
Reasonable requirements (e.g. no CS degree required for a junior level frontend position)
Specifically calls out personal traits like kindness or empathy as desirable

What can I ask in interviews to vet the position?

Remember that interviews are your chance to interview them as well. Examples of questions you could ask include:

What best practices do you think have made your team successful?
What kind of developers thrive at your company?
How do you support developers when they come onto a team?

How frequently can I change jobs?

This is a hot topic, but varies by which part of the industry you’re in. Early on, hopping jobs more quickly is fine. 3 jobs in your first 3 years? Not uncommon. Working in startups especially can lead to shorter tenure as companies fail or are acquired.

However, there are skills and wisdom you will only be able to build by staying longer. For example, no amount of training or reading will result in the wisdom you gain by wrestling with a technology decision you made over a year ago as you watch it cause painful issues.

The resume to avoid building is the one with only <2 year tenures over a 10 or 20 year career.

Happy growing!

Adam

Adam Steel is the VP of Engineering at TrueCoach. He lives outside Boulder, CO.

Act like an owner

Dear new developer,

I’d like you to close your eyes and put yourself in a couple of situations.

First, think about a car you have owned. If you haven’t, think of something else that you own and take care of.

I have owned an automobile. I changed the oil regularly in my car; okay, that’s a fib, I paid someone to change it, though.

I took care of any warning lights that came on, even though almost every visit to the mechanic resulted in bills. I definitely avoided driving over potholes. I listened for out of the ordinary sounds and, if they persisted, visited that same mechanic.

My cars aren’t maintained in mint condition. My current car has some dents and scrapes. I drove a car with a crack in the windshield for about 7 years. But, fundamentally, I take care of cars I own. Cosmetic dings are ignored, but root problems are addressed.

Second scenario. Have you ever rented a car? If you’ve owned a car, how would you contrast the level of care for a rental? (If not a car, how about a home?)

I have rented cars. I’m no dummy, I don’t want to lose my deposit or have the rental car company charge me when I return the car. I take some care. But I certainly don’t care for a rental as carefully as I do a car I own.

Hitting the occasional pothole doesn’t bother me. I certainly wouldn’t pay to have the oil changed.

With a rental, my incentives are different; all I really have to do is get it back in much the same shape at the end of the rental period.

Enough with the car analogies. Let’s talk about work.

When you are an employee, you are trading your time for money. When you are an owner, you are building a long term business. (How long? Some times for years, sometimes for centuries.)

Having been both an employee and a owner, I can tell you that being an employee is much like renting a car. A few issues here and there, especially if they won’t cause problems for years, won’t bother you too much.

Being an owner, however, is more like owning a car. You want to, at a minimum, take care of the fundamentals to keep the engine running. Depending on how mature the company is, you also may spend a lot of time tuning and improving the business, just like a car owner might invest in better shocks or tires, or change the oil themselves.

So, what’s this letter really about? Take an ownership mindset. It will set you apart from all the employees that are just treating the company like a rental car.

Some things you can do:

Ask “how will this change affect the codebase in 2 years? In 5 years?” You don’t have to do this all aloud all the time, but even asking yourself this question before diving in can help you make the change in a way consonant with the overall codebase.
Document code, processes and decisions. Two very valuable areas to document are confusing things and project setup.
When you encounter a bug, if you don’t have time to fix it right away, file an issue for future reference.
Write tests.
Talk to team members and try to understand why things are they way they are.
Interact and learn about other parts of the business.

However, just because you have an owner mindset doesn’t mean you should do everything an owner does. If you are an employee, set boundaries. An owner of a business can, and sometimes must, work beyond normal hours. They will reap the rewards of this extra work.

When I was building the MVP for a startup I co-founded, I worked every single day for a month. (Others have done far more, of course.)

But if you aren’t really an owner, set boundaries, particularly around your time. Why? Because at the end of the day, employment is still a trade of time for money. The residual value and control of the company rest with the legal owners.

In short, during the work day act as if you are an owner of the company. This long term view will differentiate you from other employees who are just trying to return the rental car and not lose their deposit. Then, when quitting time comes around, focus on other parts of your life, because it isn’t your business.

Sincerely,

Dan

You’ll always be learning

Dear new developer,

One thing I love about software development is that you’ll always be learning. This is because of two things.

First, there’s better and different hardware. It is possible that this pace will subside sometime, but looking at the variety of new computing hardware, sensors and components that have been created over the last 60 or so years gives me confidence that we’re at the beginning of computing becoming a utility, just like electricity. This is one of my favorite essays on the topic. This new hardware gives rise to new capabilities. Just like GPS in the phone gave rise to Lyft and Uber, I think that small connected sensors everywhere will give rise to new companies and software development opportunities.

The other reason why you’ll always be learning is that software itself is evolving. This is a very young profession. I believe at some point it’ll be as established and systematic as, say, civil engineering, but I think that’ll be decades if not longer in the future. That means that practices and tools are continuing to evolve. They both take advantage of new hardware, of practices learnt from other disciplines, and of lessons as systems are built. I already gave you an example of the first, but an example of practices lifted from other areas of knowledge is chaos/resilience engineering. An example of the last lesson is containerization and immutable infrastructure.

If you choose to be a developer, your career will be filled with learning. Enjoy.

Sincerely,

Dan

Learn curl

Dear new developer,

If you interact with web APIs at your job, learning curl is a good investment. Curl is a flexible, powerful, command line utility which lets you make HTTP requests.

In my current job, I build a lot of API requests. Side note: I’m going to use the shorthand API for web based, JSON API; there are many other kinds of APIs, but curl is mostly useful for this type of API.

I’ve found familiarity with curl to be very helpful as I create, share and debug these API calls.

Why learn curl?

With curl, I can easily script up API interaction. In the next section, I’ll discuss the common parameters I use.

Curl works across multiple platforms. It’s a lowest common denominator tool and is present everywhere. It doesn’t require anyone to install anything. (Okay, maybe not true on vanilla windows, but as soon as you have any unix based system, you have curl.) Update 7/21: curl is present on vanilla windows 10. Open up a cmd window and run curl and you’ll see curl: try 'curl --help' for more information.

You can share scripts with team members, add them to issue comments for provide bug reproduction steps, and version control them if you want to improve them over time. I find them especially helpful for issue reports, as there’s no ambiguity with a script.

Curl pairs nicely with jq (which you should also learn); you can pipe the output of curl directly into jq to get understandable formatted JSON.

I find when I use a low level tool like curl, I’m forced to have a deeper understanding of the problem than I would if I used a higher level tool. It’s kind of like a text editor in that way.

I haven’t run into a situation yet where curl couldn’t interact with an API in a way I wanted, though sometimes multi step interactions like an OAuth authorization code grant can be a bit cumbersome. You can set headers, provide cookies, send a request using any HTTP method, and provide data either inline or via a file.

Basics of curl for APIs

Here are the main switches I use with curl for API interaction.

-X <method> lets me specify the HTTP method, so -X GET is a get request and -X POST is a post request. Sometimes the HTTP method is implied by other switches, but I prefer to be explicit.

-H <header> lets me specify HTTP headers. You can use this many times in one command. Often if I’m sending JSON in a post with an authorization header, it’ll look something like -H 'Content-type: application/json' -H 'Authorization: Bearer APIKEYHERE'

-d payload lets me specify a payload for a post or put request. This will often be JSON: -d '{"foo":"bar"}' It can be multi-line if needed. I use single quotes around the JSON to avoid having to escape double quotes. If I need to have a shell variable inline, so that I can extract some text which changes often, I do something like this: -d '{"foo":"'$BAR'"}'

-d @payload lets me put the payload in a file and have curl read from that file. I use this switch less often, because I’ll usually put everything in a shell script anyway.

-vvv lets me see the back and forth of the HTTP requests and response, and also status codes.

As previously mentioned, I also usually wrap everything in a shell script so it is repeatable. On occasion, I’ll even check the shell script in, so that others can use it. This is useful if it is a part of a run book or troubleshooting guide, for example.

Here’s a typical curl shell script, in all its glory:

API_KEY=...
USER_ID=...
curl -vvv -H "Authorization: $API_KEY" -H "Content-type: application/json" -XPOST 'https://api.example.com/user/'$USER_ID -d '{
  "user" : {
    "name": "Dan",
    "blogger": true,
    ...
  }
}'

There’s a lot more available with curl; the whole man page is worth a read. But I hope I’ve convinced you that you can use curl to interact with APIs in a way that is:

repeatable
shareable
versionable

Alternatives

There are many alternatives. I am a bit familiar with postman, which is a web based application that lets you organize and call APIs. There is also a command line runner for postman called newman. Insomnia is another option that some of my team members use. It’s another GUI client with a corresponding CLI client called inso.

While I haven’t dug deeply into these alternatives, at first glance it seems to me that they give you tooling power and richer collaboration. But nothings free; you lose ubiquity and simplicity.

curl is a powerful tool, available everywhere, for examining and interacting with APIs. Learn it well.

Sincerely,

Dan