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

Meetings are work

Dear new developer,

I remember when I started out, I thought meetings were a waste of time.

All those people in a room (now a Zoom), discussing an issue. Folks would go back and forth, and at the end of the meeting you’d hopefully have a decision. But often the output was just more research or discussion. You might have to go back to the client, the team, or vendor and ask more questions. This would be followed, you guessed it, another meeting to relay the results.

I just wanted to code! I wanted to be told what to do, or if that wasn’t an option, take my best reasonable guess, and program.

Meetings sure seemed like a waste of time.

Now, many years and meetings later, I realize that meetings are really work. They help align teams, ensure you are building the correct things, and share knowledge. These are key parts of delivering software and making sure that all the programming isn’t for the lost cause.

Yes, you can do many things asychronously. I enjoy flexible work hours and chat tools and pull requests and email lists. But whenever I see an email or other async conversation look like it is going to go off the rails, I jump in and suggest a meeting. It may be a pain, but it will let you cut through days of unclear emails. For example, I remember meeting with a vendor in India at 8pm at night, because that was the time that was least inconvenient for the both of us. We were able to resolve questions we’d been exchanging emails about for days with thirty minutes of conversation.

Meetings define and push the work forward every bit as much as programming.

Sincerely,

Dan

Avoid toxic environments

Dear new developer,

Avoid toxic workplaces. I wish I didn’t have to write this, but there are enough stories out there (here’s a few on HackerNews) that I feel I should.

How do you know? If you have to ask if an environment is toxic, it probably is.

There are levels of toxicity, of course. Fundamentally it is about a lack of trust between you and the organization, but can take many forms. Some blatant indicators:

  • yelling
  • belittling
  • disrespect
  • verbal abuse
  • throwing things
  • empty promises

Avoid these kind of environments. If you come across one while interviewing, give it a pass.

If you accidentally find yourself in one (after all, you could have misread signals in an interview or the situation at a once-happy company could degrade) leave ASAP.

You may not recognize you are in a toxic workplace, but your body might. Listen to yourself. Notice how you feel about going into work. Having a bad day here and there is not unusual, but regularly dreading work is an indicator; dig deeper and try to understand why.

Or try other ways to gain insight. Track your mood on a scale from one to ten for a month or two. Keep a journal if that’s your bent. Ask your friends for feedback on how you like the position and how your mood is.

Avoid toxic workplaces. You may learn some skills but it will come at an emotional cost.

Sincerely,

Dan

Set your boundaries

Chain link fence

Dear new developer,

A few years ago, I suggested you over-index at your first month or two on the job. I stand by that advice. Extra effort up front will earn you a reputation as a good employee. I also think that first impressions matter; plan to make a good first impression with your team and manager.

On the other hand, it is important to set your boundaries and learn how to say no.

How can both statements be true? The answer is that you must thoughtfully consider what you want.

Reasonable boundaries

Corey Quinn wrote a great tweetstorm about what to do when you start a job. The whole thing is worth a read, but I wanted to call out one piece of advice in particular, “begin with reasonable boundaries”:

What’s reasonable? Ah, there’s the rub. You want to balance being a team player, helping your company succeed and not being abused. Because there are companies out there that will abuse you. For the past couple of years, the job market for developers, especially once you are no longer “junior”, has been stellar, but that won’t last forever. And there are firms out there whose whole business model is to hire developers, place them in soul-sucking positions or places they can’t be successful, wring them dry, and start anew with another set of developers. Avoid these places.

Other jobs will be less obvious about this, and may not even be intentional. It could be an organizational flaw or a historical artifact that the company’s success depends on violating norms around work life balance for their employees. In any case, considering and setting your own boundaries will ensure that you are “working to live”, not “living to work”.

Think about time and effort you want to invest, both on the job and in side projects. I can’t offer you specific guidance other than to write down what you are thinking and revisit it periodically (every quarter or so). Map what your current job expects with what you are willing to give, too. If the expectations diverge, that’s a signal it is time to move on.

After you have determined your boundaries, set them. As Corey suggests, one way is to set an alarm and leave work at a regular time. There are many other ways:

  • Don’t check work emails outside of work hours.
  • Ask for more money if you are expected to wear a pager (if it wasn’t part of the job description).
  • Avoid tasks beyond your job description (unless you want to take them on).
  • Don’t install slack on your personal phone.
  • Turn off your notifications.

Don’t be flagrant about your boundaries, but be firm. “I’m sorry, I can’t do that” is a phrase you’ll want to use regularly. Some flexibility will help: find out what team norms are and work within them as best you can. For instance, if your whole team starts work at 10am, then align your hours: stop work at 6pm, not at 5pm. You’ll have an easier time maintaining boundaries if the team doesn’t view them as counter productive.

When in doubt, have a conversation with your manager at your one to one. It may be an awkward conversation, so a good way to start is to ask the manager about how they manage their boundaries.

Crossing boundaries

As a software developer, there will be times when you’ll break your boundaries. At the end of almost every project I have worked on as a developer, there was “crunch time”, where I worked more hours than usual. Not 80 hour weeks, but more than 40. This is in part because estimation is hard. There are surprises at the end of every effort. Examples include:

  • New requirements that weren’t clear at the beginning
  • Tasks that the team should have done earlier but forgot about
  • External changes that require software to change as well
  • An accumulation of schedule slips from earlier in the project that pile up at the end

In some cases you can push back on these surprises by shifting dates or cutting functionality; in other cases you just need to grit your teeth and deal with it.

Break your boundaries rarely and intentionally. If it becomes a regular occurrence, consider other employment.

Sincerely,

Dan