Dear new developer,
This post by Erik Dietrich covers the situation where a developer becomes an “expert beginner”. This is something to avoid as you build your career–don’t work in a place where you are isolated or unable to progress. He breaks progress in any area down into a number of components–Beginner, Advanced Beginner, Competent, etc.
As such, Advanced Beginners can break one of two ways: they can move to Competent and start to grasp the big picture and their place in it, or they can ‘graduate’ to Expert Beginner by assuming that they’ve graduated to Expert. This actually isn’t as immediately ridiculous as it sounds. Let’s go back to my erstwhile bowling career and consider what might have happened had I been the only or best bowler in the alley. I would have started out doing poorly and then quickly picked the low hanging fruit of skill acquisition to rapidly advance. Dunning-Kruger notwithstanding, I might have rationally concluded that I had a pretty good aptitude for bowling as my skill level grew quickly. And I might also have concluded somewhat rationally (if rather arrogantly) that me leveling off indicated that I had reached the pinnacle of bowling skill. After all, I don’t see anyone around me that’s better than me, and there must be some point of mastery, so I guess I’m there.
This post is worth reading in whole. It resonates with me because I’ve spent most of my career in small companies. I do that because it fits best with my desires and my life goals. But I’m acutely aware that as I become more experienced, I am typically one of the most experienced technical folks in the room. This is a problem, because I could believe that I had most or all of the answers based on my experience (what the Expert Beginner believes).
I strenuously combat that by engaging with my peers in person and online, and I think this is a great way to do so. It’s not as deep an engagement as working with them, of course, but affords me the ability to work at small companies.
Ways to engage with the larger software community include:
The work environment you are in is a great place to level up, but depending on your situation, you may end up with few people you can learn from. In that case, it is imperative that you improve yourself through engaging with the larger software community.
Dear new developer,
Reading code is much more common than writing code. Some might even say, “don’t trust any documentation, read the code,” though I consider that to be a pretty radical position.
But how can you effectively read the code. This post from selftaughtcoders.com gives a good explanation:
Find one thing you know the code does, and trace those actions backward, starting at the end.
Rinse and repeat.
It’s a wonderfully self-perpetuating cycle: you read more code; you gain the ability to understand it quicker and more effectively; so you are able to consume even more code; and so on.
And it doesn’t stop there: you’ll also see huge positive gains in your own coding.
I know nothing about his courses, but his insight into reading code to build intuition about programming and development in general is spot on. I tend to do this through code reviews, reading blog posts and going to meetups rather than tracing code paths, but reading code can be a good way to level up. Github is your friend.
Dear new developer,
If you are sure where you want to go in your shiny new development career, pick that and follow it. Whether that is embedded programming or high frequency trading or generic web development, pursuing a career with focus is a great option.
If you are just looking for that first job, remember it’s a numbers game and just keep applying and networking. Then take the first job that seems like it’d be interesting and treat you well. (Avoid those that play games in interviews.)
If, however, you are looking for a tour across technologies, domains and businesses, and you want to work in an environment where everyone’s effort counts, I’d suggest starting at a small consulting company. This is where I started. I didn’t really know what I was looking for, but interviewed at some big companies like HP. I ended up getting an internship at a small web consultancy where I was employee number 61 (I believe).
By small, I mean between ten and seventy five people. Ten or more is big enough to hire new developers and give you some kind of structure. Less than ten means that you’ll have a lot more autonomy but that may be problematic when you want to learn from others–they may be too busy to help you.
Seventy five or less people means that every hire matters, and that you’ll be able to have a real relationship with everyone at your company. Larger than that means that people will start to be able to hide and not do real work. Small companies don’t have room for people not pulling their full weight, but bigger companies can.
I’ve written about this here as well. An excerpt of some other benefits:
- Variety is the spice of consulting shops, so if a project isn’t working for you, you can often work on another project. If that isn’t available, the project might take months. This is hard, but a far cry from working on a product for years.
- You will get as much client interaction as you want. As a developer, the ability to work with non technical people to build software to spec and on (or, to be honest, near) budget is a very valuable skill to have.
In general, working at a small consulting company is a great way to get a wide variety of experience. If you do a great job (especially at the beginning) and keep track of people you work with, it can set your career up for the rest of your life. I am still working and keeping in touch with people from the first consulting job I had, which was two decades ago.
Dear new developer,
This post from Charity about the choices you face as an engineer, and the challenges of technical management, is wonderful. As a new developer, you’re probably a few years away from thinking about that (but perhaps not. If you join a startup rocketship, it’s possible you’ll be managing people in months). But you have to manage your own career, and moving into management is one of the main career paths for a developer. (I’d say the others include: starting a business, becoming a senior developer, or becoming a consultant.)
Charity talks about how management is an entirely new skillset, and how being a technical leader plus a manager is a great way to get amazing things done. She also covers the negatives of “climbing the ladder” to ever more senior leadership. Charity doesn’t mince words:
Your job [as a newly minted technical manager] is to leverage that technical expertise to grow your engineers into great senior engineers and tech leads themselves. Your job is not to hog the glory and squat on the hard problems yourself, it’s to empower and challenge and guide your team. Don’t suck up all the oxygen: you’ll stunt the growth of your team.
I mean, there’s a reason we don’t lure good people managers away from Starbucks to run engineering teams. It’s the intersection and juxtaposition of skill sets that gives engineering managers such outsize impact.
One warning: Your company may be great, but it doesn’t exist for your benefit. You and only you can decide what your needs are and advocate for them. Remember that next time your boss tries to guilt you into staying on as manager because you’re so badly needed, when you can feel your skills getting rusty and your effectiveness dwindling. You owe it to yourself to figure out what makes you happy and build a portfolio of experiences that liberate you to do what you love. Don’t sacrifice your happiness at the altar of any company. There are always other companies.
I don’t tell you this now, new developer, because I want to scare you away from management. I’m an engineering manager right now and it’s a wonderful place to be. You have autonomy, you can help fix problems you see in your organization, and you get to recruit and help grow people into the best developers that they can be. But just be aware that when you get to a certain level, it’s a one way path away from some of the most fun parts of software development–building things, solving hard technical problems, and being a doer.
Please read the whole post from Charity: Engineering Management: The Pendulum Or The Ladder
Dear new developer,
Seth Godin writes every single day on a variety of interesting topics. He’s been blogging for years and years. Definitely an interesting person to follow.
I saw this post on opportunity cost in my RSS reader (you should use one) and thought it was an interesting take on all the free content out there. Of course, the content is free in terms of money but not in terms of attention.
From the post:
And the internet has raised the opportunity cost of time spent.
Our access to the world of learning and online resources means that the alternatives are far more valuable than they used to be.
You’re about to spend 11 minutes perfecting an email to a customer. You could do a 90% ideal job in one minute, and the extra 10 minutes spent will increase the ‘quality’ of the email to 92%.
What are you doing with your free time? Are you conscious of how you are spending it? Are you aware of the opportunity cost of say, reinventing the wheel, learning a new technology, responding to a off base comment in an online forum?
Time is your most precious resource. Where you invest it when you are starting out will compound over the years.
I’m not saying “Don’t have fun.” I’m saying understand the consequences of your choices and accept them with your eyes wide open. Realize that the cost of learning a new skill has plummeted due to the Internet, which means the relative cost of anything else has increased.
Dear new developer,
It’s great to see what other developers have learned, especially when they are just starting out.
This is a post covering Mitchell Irvin’s lessons from his first two years as a software developer. Now, I don’t know Mitchell at all (but I guess I am connected to him in the third degree, according to his LinkedIn profile).
But his lessons resonated with me. Here are his lessons:
- Your relationships with your coworkers (interpersonal/leadership skills) and your technical prowess (hard skills) are equally important
- Your ability to influence others is most prominently determined by your ability to help them reach the same conclusion you did, on their own
- It is the mark of a great problem solver to ask many questions before beginning to think about a solution
Each of these is worth a blog post, but I’ll let you click through to see how Mitchell arrived at each of these–some good anecdata.
However, I think that the bigger point is not what Mitchell said, though he has good points. There are two interesting meta points:
- Mitchell reached me without me knowing him, or knowing anyone who knows him. This is the power of writing, especially a blog. You never know who you’ll connect with.
- I checked his arguments against my experience and found it resonated. This is a great way to judge new data that comes at you (and, as a software engineer, a lot of information will flood toward you). But you also need to be aware of your innate biases, and think about how the points in any post or article could be false. You also should consider the source. Mitchell has worked at a couple of large companies and his experience may not be applicable at a different type of company.
Being an information consumer and producer is a key part of being a software developer. You should work on your writing to produce information. And you should be thoughtful about your information consumption.
Dear new developer,
I already covered the right way to ask questions, but this post was so good that I wanted to share it. (I found it on hackernews.) Mike Ash gives advice on how to get answers from the internet.
Tips like “explain everything up front”, “post your code” and “follow up after you get an answer” will make it more likely that when you post a question on a forum, you’ll get some kind of help. The whole thing is worth reading, but here’s an excerpt that really resonated for me:
Many conversations I see indicate a subtle, buried belief that the list or chat is some kind of answer machine, and the key to obtaining a good response is to hunt around until the precise required format for the question is found.
It’s not a game, you’re talking to real live people. Treat them just as you would treat people you’re talking to face-to-face, and you’ll get much better results.
I have been one of those newbies under pressure to get something done. I’ve seen comments on github that lead to statements like this. It’s easy to forget that the folks helping you are
b) not getting paid by you
No matter how obvious the bug seems, or how much it is impacting you, you have to treat people helping you kindly. (You should do that even if you are paying people, by the way. If your boss doesn’t respect you, find a new boss.) Anyone who has run a volunteer organization knows that respecting the volunteers is the first step to getting anything done. Every time you ask a question on an internet forum or mailing list, you are essentially tasking a set of volunteers. Treat them right.