Stressed? It’s Not the Industry, It’s Your Employer

Blog posts and discussion threads about the overwhelming stress felt by those in the software industry seem increasingly popular of late, and authors usually infer that the pressures (or combination thereof) are highly unique to software. The commenters usually skew young, but there is no shortage of experienced pros echoing these sentiments. There are clearly characteristics of the software business that might lead to the belief that certain burdens of a software career just “come with the territory”.

I’d like to offer an alternative viewpoint to anyone who feels these pressures are unavoidable. Not only are many of the stressors cited by software professionals not remotely unique to software, but many of these stressors are entirely foreign to a large percentage of the industry in many parts of the world. In other words, these problems aren’t that “special” and are often symptoms of a toxic employer more than a toxic industry.

What are the main complaints and concerns heard from those in the software industry?

Unpaid overtime — It seems as though the younger generation feels that 70+ hour weeks are the norm and not the exception, which may be a function of their observations of a small subset of the industry. I have represented hundreds of companies with a client roster that includes a mix of startups, mid-size firms, and Fortune 500s, and the number of development shops expecting even 50+ hours is dwarfed by those asking for something resembling 9-5.  Your experience may differ.

There will be occasions where even a straight 9-5 turns into 9-midnight, but that isn’t specific to software. Talk to a retail manager about their holiday season hours or ask your accountant to dinner and a movie in March or April (in the US). Every industry has peak times, so unpaid overtime is hardly unique to software.

Most unpaid overtime situations are simply explained. Employers who consistently ask for unpaid overtime are understaffed, and employees that aren’t interested in working those extra hours need to either refuse or find a new job. Companies can get away with asking for more hours when the economy is down. Right now (and for the past few years) it’s a seller’s market, and finding a new job (particularly while you still have a job) isn’t the challenge it can be in other industries.

Attitudes are starting to change and more companies are asking for less time, which may be due to more accurate metrics on how increasing hours does not always result in better project outcomes.

Pressure to deliver on time or fear of failure — Clients (whether internal or external) can be irrational beings with unreasonable expectations, and some projects are destined for failure from the start. Inept management, insufficient resources, or improper tools might make developers feel helpless to remedy the situation.

Are tight time constraints indigenous to the software industry? There are many instances where speed to market is a factor, but an unreasonable timeline can also simply be poor (or overly-optimistic) estimation. Skilled managers don’t regularly overpromise and underdeliver, and companies that care about their employees will protect them from forced marches.

Companies committed to avoiding failure will have systems in place to reduce risk. Complaints about fear of failure often are accompanied with details about the employer having no QA/testing, the absence of process and any real development methodology, outdated tools, or no source control. In other words, if your employer miserably fails the Joel Test you may be more likely to feel pressure. Many who stress over fear of failure are working under conditions where success would be unlikely.

These also are not unique to software.

Competition/keeping skills fresh — I think this is the most valid of the perceived pressures due to the speed in which technologies can become popular and unpopular. By the time anyone gets productive using the hottest JavaScript framework, a new one has replaced it.

Some individuals feel it’s necessary to invest many unpaid hours keeping their skill sets up-to-date to maintain marketability. In technology skill markets characterized by low supply and high demand (see AngularJS today), most employers eventually lower a requirement with the expectation that the skill can be learned by an accomplished professional.

The desire to invest in self-learning can be innate curiosity, but the perceived need to invest time self-learning is largely a function of the challenges provided by an employer. Those who solve complex technical problems with desirable tools by day have less to worry about at night.

Impostor syndrome — This gets bandied about in discussion forums to the point where it sometimes becomes comical, which is unfortunate for those who truly feel it. Saying “I have impostor syndrome” may be becoming an acceptable way of saying “I’m probably a better programmer than I think I am, right?“, and I can’t imagine that the condition is under-(self-)diagnosed among newer industry entrants.

Impostor syndrome probably isn’t directly related to an employer, although how a company does code review/pairing/testing may expose a developer’s work to more open scrutiny than those in other fields. If you are junior level and feel that you know less than the others at your company, you’re probably right – but it has nothing to do with a defect. Wait a few years before diagnosing yourself.

Uncertainty — A client spec that changes with the weather. A potential project that is yet to receive funding approval from stakeholders. A bootstrapped startup with short runway. These are all uncertain conditions common (but not unique) to software, but they are not unavoidable. Restaurants are also noted to have picky customers and high failure rates.


By many studies and surveys, software developers have one of the best (and best paying) jobs in the world and demand for those skills is possibly as high as it has ever been. Lots of careers are stressful, but we should be careful not to confuse which stressors may be somewhat inherent to the industry and which are signs of an undesirable employer. We may be scaring off some good coders.

How To Leave Your Job: Preparation, Resignation, and Transition

Making the decision to leave an employer and submitting a resignation is typically an emotional experience, and can be stressful the first few times one goes through the process. Valuable business relationships, friendships, and even legal/financial standing can be in danger if things aren’t handled properly. If you anticipate an upcoming job change or are deep in the interview process with a potential new employer, start considering the following:

Review Contracts

Some employment contracts contain clauses regarding the amount of notice required or non-compete limitations on who you can work for and what type of work you can do. When interviewing with companies, it’s helpful to properly set the hiring party’s expectations regarding your availability and any possible snags. Even if these restrictions may not be legally binding, you should read over any signed documents and consult an employment attorney if you have any concerns.

Keep a Low Profile Until the Ink is Dry

It is not ideal to have a current employer discover your job search while you are in the interview process and before you’ve received offers. A manager might get tipped off by several clues or combinations thereof, such as unusual use of sick/personal time, lengthy calls taken on mobile phones in the parking lot, or a sudden spate of LinkedIn activity. If you feel the need to share information on your job search with co-workers, proceed with caution. Be particularly careful if providing references from your current employer, as they may be called immediately (before an offer) without your knowledge by recruiters or hiring managers.


Opportunity doesn’t always knock at the perfect time, but to avoid burning any bridges it is ideal to synchronize your new job’s start date with the end of a cycle at your current employer (a deliverable, initiative, sprint, etc.). This is not always possible due to the nature of the business, but it’s something that should be kept in mind and addressed during the interview process.

Resignation Letter

No matter how small and non-corporate your employer, you should always write an official resignation letter (even if you deliver the news initially in another format). The resignation letter should be short, direct, and written to serve a few purposes.

  1. Notifies the employer regarding your last day of employment.
  2. Expresses gratitude to the employer and co-workers.
  3. Assures the employer that you will be productive during your notice period and helpful in transitioning reponsibilities and knowledge to replacement(s).
  4. A positive close.

Please let this letter serve as notice of my resignation from $COMPANY, with my last date of employment being $DATE. 

I greatly appreciate the opportunity and all I have learned and accomplished during my employment with $COMPANY. I hope to make my remaining time here as productive as possible to transition my knowledge and responsibilities to my co-workers or to help select my replacement.

Thank you for the opportunity, and I wish $COMPANY and my co-workers success.

Some are tempted to turn a resignation letter into a treastise on the state of the company with criticisms and suggestions for improvements, while others feel the need to provide multiple details on where they are heading and what they will be doing. These topics are not appropriate for a resignation letter, and the template above is as much information as you should offer in writing.

Transition Period

Once you’ve resigned from a position there are several possibilities as to what might happen, ranging from counteroffers to “pack your desk and GTFO“. Regardless of  the direction things go, your willingness to be cooperative and helpful during the transition period is one of the most important factors impacting your ability to use employees from the company as future references. I’ve conducted thousands of reference checks in my career, and references are often eager to share details of how an employee made a non-graceful exit.


Changing jobs can be a stressful time, particularly if you don’t have a plan. These steps can help in making a smooth transition to new employers while preserving relationships (and references) from your past jobs.

On Job Titles: Juniors, Roman Numerals, and the Elusive “Python Architect”

As I spent the last week of 2015 updating some database records on my candidate network, I began to notice various job titles and how the industry uses a variety of naming conventions for people who ultimately do similar things. I’m sure this isn’t exclusive to technology, but there are industries that appear to have more defined terminologies.

Some thoughts:

Junior Software Developer (or Engineer, Sysadmin/etc.) — What is the benefit (to anyone) of including the term Junior in a job title? When we post open jobs, using the word Junior is valuable to discourage those who will be seeking responsibility and/or compensation well above the level the job provides. But once someone is in the door and hired, doesn’t the Junior title do more harm than good. A team member with the Junior title might be more responsive when pitched jobs that don’t include Junior, with the thought that it is a step up (even if the repsponsibilities and compensation are identical).

Couldn’t we just use the title Software Developer without the somewhat demeaning prelude, and then use more positive terms to reflect seniority?

Roman Numerals — The use of Roman numerals to indicate seniority seems to be exclusive to the enterprise monoliths, and I’d hope that some of these firms would reconsider their titles. I’ve never personally seen a startup or even mid-size company that uses them.

The numerical use is particularly unfortunate when common criticisms of these organizations are phrased “you’re just a number at $COMPANY”, as the concept of being unimportant to an employer is directly equated with numbers. The use of numbers allows for many specific levels within one job title, which primarily seems to serve in limiting an employee’s ability to negotiate compensation. “We can’t pay you $125K until you are Architect IV. You’re only Architect II.

Where are the Python Architects? — The Architect title has always been a bit of a hot topic. When my business was focused entirely on Java and my clients were larger firms, I saw it every day. Now that I work mostly with startups (most not choosing Java as their primary language) it’s rare that I hear the term from job seekers or hiring clients, except as a verb.

Architect means “I don’t write code” to a segment of the industry, which some seem to translate to “I’m above writing code”. I believe this is the ultimate source of any controversy about the title, and it’s obviously not the case for many who do code or at least don’t feel they are “above” coding because of their title and status.

I rarely (if ever) see the title Architect used in combination with a language or platform other than Java or .Net. (ASIDE: Almost half the 6K Google hits for “Python Architect” go away if you ignore the hits for the Monty Python architect sketch.)

Ninjas and Rockstars — It seems the industry has finally moved away from these references, thankfully. The connotation was often negative and the terms today probably scare away more applicants than they attract.

When Job Hopping Goes Wrong

While surfing a thread about a potential job change in Reddit’s /r/cscareerquestions (DISCLOSURE: I’m a mod), I read the following comment:

“There is no such thing as ruining a career by switching jobs too often”

At the time this was the most upvoted comment in the thread, which troubled me because it is rather poor advice. I’ve written about my appreciation for job hoppers once or twice in the past, but I would never suggest to a reader that unlimited job changes would have a positive impact on a career.

When evaluating candidates that appear to be job hoppers, there are at least a few things that need to be considered.


A pattern of job hopping combined with multiple periods of unemployment is a huge red flag unless there are verifiable explanations for the gaps. Resumes depicting a number of employers > number of years AND one or two periods of unemployment for a given time period will require some explanation, and sometimes the explanation is a confession.


The job hoppers that have the most success are those that tended to finish a job and move along. The developer who built the system but didn’t stick around to support it, the smokejumper that was hired into a difficult situation to accomplish a specific task, and the person who worked herself / himself out of a job are generally not faulted for frequent moves.


Some job hopper resumes show regular increases in responsibility or employer reputation, while others may be reminiscent of a downward career spiral. A series of job changes that reflect upward career mobility isn’t indicative of a problem child, but rather a rising star that perhaps hasn’t found the appropriate level of challenge.

Comfortable in Their Own Skin

You should be able to spot a job hopper that might become a questionable hire by listening to them describe the motivations behind their choices. There should be a level of both transparency and confidence in their explanations, and they may even admit situations where they made a wrong move. Candidates who fess to being blinded by an employer who made empty promises in interviews or presented an offer nobody could refuse should gain some credibility points. Whether they are excellent employees or not, all job hoppers should have some expectation that they will be asked about their moves, and those most reluctant to discuss their history are likely the ones requiring deeper investigation.

The Recruiter Manifesto

It’s no secret that many agency recruiters behave unethically. As much as I enjoy getting paid to help companies grow and to assist job seekers in finding better opportunities, it is sometimes difficult to be enthusiastic about my industry. There is a segment of the technology population that assumes I must be unethical based on the industry I’m in, which is frustrating.

I’m optimistic that the industry’s reputation will improve as more recruiters are exposed for behaving badly and eventually leave the industry. First we need to have a set of expectations for recruiters to follow.

I believe that every recruiter should agree to the following conditions, and I’d encourage readers to refrain from dealing with any recruiter unwilling to pledge to these guidelines.


Where the candidate stands — Candidates are entitled to know where they stand in the hiring process. This includes information on whether or not an offer has been made to another candidate, whether they are still in consideration, the length of the search, and some idea regarding the number of other candidates in competition (if known).

How the recruiter is paid — Candidates are entitled to know how the recruiter’s fee is determined, which provides candidates at least some insight regarding the recruiter’s personal incentives during the process and any negotiation. This includes information on whether the search is contingency or retained and whether the fee is flat or based on compensation. For fees tied to compensation, the recruiter should reveal which elements of compensation (salary, bonus, stock, signing bonus, etc.) are included in the fee determination and which are not included.

The recruiter’s experience and relationship with a hiring company — Candidates are entitled to know how long the recruiter has been working with the hiring company and at least some details on the level of success (whether a placement has been made in the past).

Honest (and ideally actionable) feedback — Candidates are entitled to know how they performed in any interviews and what they could have done better. Keep in mind that both companies and agency recruiters have virtually no incentive (and actually may incur liability) beyond goodwill to provide interview feedback to rejected candidates, so agency recruiters may not always be privy to detailed feedback. Recruiters should make efforts to get detailed feedback whenever possible, and deliver that feedback in a timely manner.

Conflicts of interest — Candidates are entitled to whether any potential conflicts of interest for the recruiter, such as a recruiter representing multiple candidates for the same role (which is common and in itself breaches no ethics).

Salary — Candidates are entitled to know if their salary expectation is above any salary range provided by the hiring company (if one was provided).

Courtesy and Integrity

Timely response — Candidates are entitled to timely responses on any requests for feedback or updates on the hiring process. A successful job search depends on good timing to optimize both available opportunities and negotiations, and any delays in the sharing of information can have a detrimental effect.

Honesty — Candidates are entitled to the truth, whether it be about the companies the recruiter represents or the details of an offer. Whenever there is obvious room for interpretation, the recruiter should defer to the hiring company to relay information directly to the candidate in order to eliminate the possibility of inaccuracies or confusion.

Honoring of requests/information sharing — Candidates are entitled to have the recruiter serve as their liaison during the process, and requests from candidates to either share or withhold certain information with clients should be honored whenever possible.


Search confidentiality —  Candidates are entitled to have their job search activities kept confidential and only shared with those that need to know. Situations that may breach that privacy, such as requests for references from a current employer, should be addressed with candidates in a way that describes any potential risks. Recruiters should not share a resume with anyone without the consent of the candidate.

Alterations of resume — Candidates are entitled to know about any proposed resume modifications that an agency recruiter may be required to make (such as adding recruiter contact information), and a recruiter should make no alterations to a resume’s content without the consent of the candidate.

I’d encourage job seekers to share this post with any agency recruiters they are contacted by, and further ask those recruiters to pledge to these standards.

Is Your Employer a “Best Place To Work” For Developers?

Glassdoor recently released their Best Places to Work 2016/Employees Choice Awards, and as you would expect the top of the list features several well-known companies from the tech sector (Airbnb, Facebook, LinkedIn, Google) and other firms that aren’t exactly household names. The rankings are based on anonymous reviews and ratings from employees, with the results crunched by a proprietary algorithm. The survey asks respondents to rate their company on the following set of criteria: Career Opportunity, Compensation & Benefits, Work/Life Balance, Senior Management, Culture & Values.

As someone who has asked thousands of job seekers about their ideal employment scenario, I have heard each of the criteria above cited on countless occasions. Glassdoor is not exclusive to the technology industry, so of course the survey criteria are rather generic and applicable to firms in any vertical.

Based on how I hear developers describe their dream job, I would add the following criteria (in no particular order) to Glassdoor’s list when ranking development shops:

Autonomy and Tool Availability

Does the company mandate the manufacturer and operating system of your laptop, your IDE, and whether or not you are allowed to use open source tools? Firms that restrict tool and language use may hinder their employees from developing marketable skill sets, which forces career-focused individuals to either develop these skills after hours or seek new opportunities.

Learning Culture

Is the company committed to allowing their employees to develop their careers through ongoing learning? This could be as simple as letting developers prototype in an unfamiliar stack, holding in-house lunch and learn sessions, formal training, or providing time-off or budget for conference and users’ group attendance.

Variation in Projects/Greenfield Work

Ten years of maintenance on a static project will not be considered ten years of experienceby a future employer. Pardon the cliche, but it may instead be deemed one year of experience ten times. Variety in project work and a favorable new development : maintenance ratio tends to make for happier employees.

Doing Things Right

Developers gravitate toward companies where they can get things done in a professional environment. How the company’s development organization scores on the Joel Test is one way employees might rate job satisfaction.


Is the daily work engaging and challenging for the employees? Even well-compensated employees will look elsewhere if their duties are no longer interesting.

Respect and Value On Engineering

Does the company see technology (and technologists) as a core element to their business, and are developers treated accordingly? This is usually evident in software product businesses, but becomes a bit clouded when technology is considered a cost center.

What did I miss?

How to READ a Job Posting

After reading a recent article on DZone about writing developer job postings I started thinking about how job seekers often read and sometimes (mis)interpret job ads. At least once every few days I encounter some rant about how unrealistic job postings are, whether on a so-called Entry-Level Job that actually requires three years of experience or a spec that appears to seek an entirely unrealistic collection of skills. Must have ten years of experience with Node.js is coming to a job ad near you!

As someone who writes job descriptions for companies, I’m not here to defend those in the industry who use a highly exclusionary style that can be off-putting for many job seekers. Until some spec writers learn to do a better job of representing what makes for both an exceptional candidate and an acceptable candidate, I think it is important that readers understand how to interpret what is written to make the best judgment on whether to take the time to apply and to further set their own expectations properly regarding the likelihood of a positive response (interview).


Some key considerations when reading a job post.

Postings (Like Resumes) Are Written With SEO in Mind

You know how some people pepper their resumes or LinkedIn profile with popular buzzwords in hopes that some recruiter will be searching for that term? Well, people writing job specs do the same thing, and writers will include what we might call complimentaryskills listings without those skills actually being considered as a requirement. A Clojure shop might include “Haskell” and a company using Redis might list “MongoDB” somewhere in the posting, as we can’t expect every functional programmer or NoSQL enthusiast to only be searching for their particular stack. Maybe the “ideal” candidate is an expert in Clojure and Redis, but the company doesn’t want to miss out on the Haskell developer either.

Postings Represent “Ideal” Candidates

In most cases a job posting is an elaborate wish list with several requirements and nice-to-haves, but hiring managers or recruiters generally don’t expect candidates to be able to check off every box from the list. Technology hiring varies greatly between companies, and in my career I’ve consulted to companies that demanded at least n years with a specific framework as well as firms open to hiring engineers with programming experience on any stack.

Non-negotiable Requirements Should be Fairly Obvious

In most cases, writers of job specs will be explicit about requirements that are truly required. There will always be companies that believe four years of Java experience is inadequate but five years is just right (without even considering how we try and justify what a year of experience even means), but most shops will show flexibility on items where years of experience is listed. It’s probably a waste of time to apply for positions with more binary requirements, such as those involving citizenship, education, or a required certification.

Look for the Gotcha

Over the past few years job post writers have attempted to verify that an applicant actually read the full post by including some obscure directive in the post. Please include your salary requirement and favorite color in your cover letter.

Format, Focus, and Culture

Readers of job descriptions should be able to draw some conclusions about the hiring company based on the format of the job spec and what content the writer chose to include and emphasize. Companies advertising for a Software Engineer IV vacancy that dedicate multiple paragraphs to describe employment policies and procedures may be more likely to have a regimented environment when compared to job specs that instead choose to include the core values of the development team.

Job postings are an opportunity for a company to both describe an ideal candidate and explain why readers might want the job. The way an employer chooses to use the space may speak volumes about how the company sees itself and how they want others to see them.