Advice to new software developers

I’ve had the pleasure of managing and growing developers for a few years. Most new developers do not suffer from a lack of skill but instead a lack of perspective. This is true both on the structure of code but also on the structure of careers.

What to do those first few years.

Most people fresh out of school are going to end up at either a product company or a consulting firm. Think carefully going anywhere else. The consulting route has the benefit of seeing many projects over a short period of time. A product company has the benefit of watching a single product evolve and the stresses that come with it.

Both experiences are valuable. However, the career options tend to be better for the person working in consulting.

Why? Because consultants are rarely hired for out of date skills. As expensive “hired guns”, they are hired to take on high-value projects that the company can’t staff internally. The internal staff is often stuck with thankless maintainance of the code produced by the consultants — regardless of quality.

Which looks better on a resume:

Part of key team writing java code to ship {major project X}, on time and on budget

or:

Wrote code in java fixing bugs for company {major product X}.

The first one looks way better. A few years at a consulting firm and you’ll have multiple projects under your belt. That means you get multiple lines on your resume and multiple things to talk about in interviews. The maintenance developer has no such benefit. As a junior developer, maintaining code is a very likely first job but it’s not great for careers. When you are the maintenance team, you are seen as a pure expense by management so they hate paying you. Moreover, the lessons learned from maintenance simply don’t mean as much. There’s also the chance management decides to toss the legacy codebase — and the team with it.

The lesson: Avoid becoming a maintenance dev for your first few jobs, if you can. Being at a product company is ok, as long as you are part of a team that makes new things to sell.

The economy right now is very strong. If you have the skills and the choice, take a job that will expose you to multiple projects, multiple managers, and multiple industries as fast as possible. That’s at one of the consulting firms or an agency.

As a double bonus, the consulting world will also grow your network extremely quickly. Since most jobs are gotten through connections, the advantage here should be obvious.

Understanding the corporate world

Politics suck, but you need to learn anyway

The other advantage of working at consulting firm is the politics. You may recoil in horror but hear me out. You know that phrase “Nothing is certain in life except death and taxes”? Add politics to the list. Like it or not, no matter where you go there will be some level of company politics. At a consulting firm, you’ll get exposed to the politics of your own company as well as others. You don’t have to like it, but you do need to learn it. In fact, the more you hate politics the more important that you are good at it, because that’s how you avoid the bullshit.

Plus, those firms tend to be performance oriented. If you are good at what you do, that goes a lot farther in a firm where your work (and billing) goes directly to the bottom line.

It’s a balance. In my experience, the less political the workplace the better it is because people are genuine teammates. But you won’t always have that luxury. Try and make lemons into lemonade by learning what you can about those environments and then find somewhere better.

Understand your industry

Software exists to solve business problems. Computer science students get exposed to algorithms and complexity analysis and then get jobs where that stuff doesn’t come up. In most languages, things like red-black trees and so on are already implemented behind the scenes. What really matters is that software gets shipped quickly and works ok. And since most software is a bunch of libraries talking to a bunch of services, you’ll be working at a much higher level of abstraction. Should you still master data-structures? Yes. But that won’t be enough.

So if it’s not low-level implementation that matters, what does? Solving problems. And to solve a problem well, you need to understand why it exists and for whom. That means understanding the business.

Thus, one of the easiest ways to make a difference and shine as a developer is to know your industry and know your customers. I’ve seen so many developers stand out like this, but it’s almost impossible to stand out just for code alone. Possible — but it happens about 1/10th as often.

Learning customer service, understanding the business, and making your life easy for your boss(es) is how to stand out. And your “boss” in practical terms is likely a project manager, product owner, business unit director, or lead developer. Three out of four of those will never look at your code. Half the time the lead may not either and just trust that to someone else. But all of them are obsessed about the product and the customer.

Interviews

Software development interviews are broken. Interviewing fads come and go, and none of the fads has any effect at all on finding the good people. In part, this is because companies don’t really have a common definition of “good”. And if the company doesn’t know who will succeed there, you better believe the interviewer doesn’t either.

Here’s what usually happens: the team is told by HR that someone is coming in for an interview. One of the developers gets tasked to “interview the new person”. They remember how they were interviewed, google “developer interview questions”, and then write a bunch down 10 minutes before you show up. Whatever they saw on Google: that’s your interview, plus a few specific questions about your past history.

These tactics are spectacularly ineffective. At best they know that you can’t be too terrible because you did something on command on a white board. Or perhaps you re-implemented a well known algorithm by hand, even though that’s never what you’ll do in the job and if you did it would be a terrible idea.

How the hiring decision really gets made

At most companies, about 80% of the choice to hire or not comes down to personality and only maybe 20% on how good at code you are. A lot of times people will get interviewed and the company’s official response is that they really want “someone with a lot more experience at X”. When this happens, it’s usually a personality thing. If they just totally loved you the response would be “Well, they don’t know X but they seem REALLY smart and they did Y which is similar, they will be fine”.

If you don’t get a job offer and you felt you did ok at the tech — it’s a personality thing. Charisma matters most.

You might think this is irrational, but it’s not. Once hired, you’d be spending 40+ hours a week with that team. Everyone prefers to go to work with people they like every day. Hiring you isn’t just gaining work capacity, it’s also taking on forced socialization with someone they just met. So work on your code, but also work on your people skills.

Feedback and documentation

Every month, document your successes. If you increased unit test coverage — document. If you were in a meeting with senior management — document. If you took on a new project, document. You want this when reviews come around and also for your own resume when it comes time to move on.

Every 3 months, proactively get feedback from co-workers and anyone who interacts with you regularly. Take what they say to heart. Most companies have terrible feedback cycles that will not help you. Typically, feedback is handled with about as much planning and thought as interviews. Your boss thinks about you for maybe an hour, grumpily writes a bunch of stuff into whatever HR system the company has purchased, hits save and sighs with relief. It’s the rare company and manager that really obsesses about growing their people. You’ll know you have one when you get constructive feedback regularly without the enforcement of the HR bot.

Conclusion

If you are a newly minted graduate or early in your career, you want to look for positions that maximize your learning not just about code, but about people. Relationships determine success at least as much as code ability unless you are a truly 1/10,000 developer — in which case start your own company.

When you are going into an interview, realize that you’ll likely be asked to whiteboard, write out algorithms, or any number of other hoops. These will probably have no relation to your actual job, but you need to do them anyway. But the real key is to be personable. Liking you as a person will go farther in a quick interview than liking your code. But if you don’t get the job, realize that it’s quite possibly nothing to do with you.

Keep going. One day, you won’t be a junior developer any more.

This story is published in The Startup, Medium’s largest entrepreneurship publication followed by + 380,756 people.

Subscribe to receive our top stories here.