You are the minion to the other managers who have paid their dues (5+ years) and want to move on to more interesting things.

So I'm going into my first lead dev role, what should I know that I would otherwise be unprepared for?

If you've been developing for a while you should already be doing most of the things you need to do as a lead (if you're going to be a good lead anyway). These include thinking more of the big picture, trying to see around corners to problems that could potentially threaten the project, mentor less-experienced devs, code review to make sure that everyone is writing code which will be maintainable over the lifecycle of the project, prioritize the riskiest pieces first to eliminate surprises later, create detailed design documents where applicable, POC new technologies to hand off to devs, etc.

The main difference in one soundbite I think is you need to change your scope to the entire project, vs. just getting your piece to work. If you're the kind of dev who already does this, being a lead should be an easy transition.

Here are some of the biggest lessons I've seen or had to learn the hard way:

1. Do whatever it takes to get the framework and architecture ready for the devs. Work nights and weekends if you have to. Otherwise you wind up in a changing-the-wheels of the plane while it's flying situation. My first time being a lead this happened and it was disastrous.
2. Code review, code review, code review. On one of my first projects for my current company I got caught up writing the mobile framework while competent but new devs were working on the full site JSP part (upgrading to a new front-end framework and look-and-feel). We found out after we went live that they had completely missed a couple of major pieces of functionality which were hidden requirements buried in the legacy code.
3. Two things that never go over well with the devs you're leading: perception that they're working harder than you, and making them do rework because you hadn't figured out how you wanted things done. I don't think I've personally fell into the first. On the second obviously there's going to always be some rework. But try to keep it to a minimum as much as possible. If it's a lot easier to do a refactor yourself than explain it, consider just doing it yourself.
4. Agree on code format standards before the project.
5. Strongly encourage devs to standardize on tools. This makes it much easier to mentor new devs when they're using a tool you're familiar with. I just say "Well you can use X. But if you use Y, you'll get unlimited help from me on it."
6. Do fun/bonding stuff every now and then, especially things that get you out of the office. The specifics of this probably completely depends on your office culture. We go BBQ in a nearby park every now and then. We had a weekend where we rented a giant house in Big Bear. I brought in a big fuzzy yellow chair that everyone seems to enjoy. Put puzzles or fun things around your desk that devs can absentmindedly play with while you discuss strategy. We also go out and drink together. A lot. It's problem. But because of all that bonding, it's guaranteed we all have each other's backs when the poo starts flying.
7. When mentoring, try to remember back to when you first learned whatever it is you're teaching. Put yourself in the mind of your pupil. It's a completely different mindset. Programming is all about brevity, teaching is all about thoroughness, even repeating tough concepts.
8. Avoid pronouns in communications. Be brutally concise. Before sending anything, go back and proofread for clarity. Tiny bits of seemingly insignficant ambiguity can mushroom into big problems down the road.
9. In the same vein, don't discount little inefficiencies that add up. If you see your dev spending an extra 15 seconds a few times a day doing some manual process, script that thing. Eventually if you do that enough, it all adds up. I call it the Jerry Rice theory. He never looked like he was doing any crazy moves, but he had complete economy of movement by studiously ironing out every tiny inefficiency.
10. Stay positive. Never let them see you get rattled. Etc. Nobody wants to deal with a grump all day.

This sounds like a situation where, if the **** flies, you are taking the fall. Sounds like you're a manager to me.

We've gone 3 years talking about testing but not doing it. I have no official duties associated with it. Worst case scenario is we just don't have tests, which is what we have now. We're a long long way off from actual continuous integration (probably forever). But good automated tests should at least be able to replace a lot of the regression testing that's currently done by the SQA team.

This is a major issue with us at work. My coworkers don't like to hang out with each other. The owners wanted to take us all out to dinner and drinking and the foot-dragging, bitching and moaning, caused the The Big Day to be delayed for months.

The second time was the same visceral reaction.

The third time got struck down unanimously.

Mind that this was supposed to be a monthly occasion.

Call me old-fashioned, but I don't consider my coworkers my friends. I have a personal life that I'm perfectly happy with, and I tend to entertain the company of people I chose to be around. I didn't chose to be around my coworkers and I don't see any reason to become friends with them. Sure, we joke and talk and I actually do like my coworkers, but these are people I have to be around for 40 or more hours a week. I don't see my friends this much, nor do I get this many hours of sleep in a week. How selfish of an employer to ask a husband to spend more time away from his wife and kids!

Some of us are truly introverted and need time to deflate and take their minds off of work. I'm forced to talk to people all day, and it take me a long time to recover from this.

There is a big difference between friendship and respect. We all respect each other, and at the end of the day, that respect and determination to do well drives our company. If I'm a friend to my coworkers, then I don't have free license to think critically about my job. If I need to fire someone or have an honest and painful chat with them, the fact that we are upholding an image of friends makes things more difficult.

My other friends in management feel like I do about this stuff. I'm not sure what is good or bad philosophy. I think either extreme is rather unhealthy, but I don't know where the center is.

I get publicly rattled quite often, but this is a result of our open-office plan, plus the owners are incredibly tense people who like to chuck mud all over the place. They once sat me and the manager down and talked expressed disappointment in our reluctance to up the pressure in our room. "You guys are just too relaxed, man." I told them the duck analogy: ducks in a pond look so calm, but their feet are cycling 100 RPM.

Just yuck.

****

One thing I've learned the hard way is that people look at me for a lot of implicit guidance. If I say "no" to one situation, they automatically assume that "no" applies to every somewhat similar situation. I've gotten blind-sided by so many situations that were brewing up that no one ever told me about because it was just close enough to one situation that they didn't bother telling me because of some prior feedback I gave.

I had a long conversation with one employee about a situation. She immediately (and understandably) pointed her finger at me and said "well, you always do X and now you just told me Y."

Well, I told her that I didn't always to X, and although I don't always tell her that I reacted to X at all, it doesn't mean that I didn't react to X, and in fact, after I list all the times I resolved X, we concluded that I only reacted to X in a way she didn't like on one or two occasions. I learned that I have to give feedback. Each little bit of reinforcement adds up. No one likes their work to add up to nothing.

Always keep promises. If I say I'm going to do something, I push it to the top and get it done ASAP. It is a strange double-standard. I'm allowed to make zero mistakes and I'm never allowed to go back on my word. Each instance is enough to make people forget many successes.

It is impossible to roll back from responsibility and pass off my work to other people. Even though I don't interact with DB Girl and her work anymore, and she is working under someone else, I still get blamed for all the things she does wrong. I'm the face of her work, and it doesn't matter that I'm removed from her is a command directly from the owners, I'm still responsible for everything that goes right or wrong. In part, I blame her manager for not stepping up to the plate and taking the reigns, but I get his reluctance as well. The simple fact is that everyone still prefers to bring all the issues to me, and I can't stop the deluge no matter how hard I try.

When the heat comes down, I'm responsible for all the mistakes, no exceptions. I never point my finger at someone else, no matter how much I'm not to blame. It is my problem to resolve the issues with my employees and it is my duty to make sure the mistake doesn't happen again, and my mangers don't want to deal with people 2 or more levels below them.

The opposite also holds true. No matter how many compliments I get showered on me, I redirect all of the good stuff to my coworkers and employees.

I put a lot of effort into keeping communications open between me and other people. Other people sarcastically call it baby-sitting, but yeah, that is exactly what it is. I know that information will make my job easier in the long-run, but I also realize that, at best, I have 30% of the information I need, but if I didn't talk to people, I'd have 0%.

I'm throwing this out there as lessons I've learned, but I'm sure all of you are itching to pick it apart and call me a moron. Please do!

Sounds like you are the perfect guy for everyone else around you. You do all the hard work, take all the blame when something goes wrong, and get none of the credit/$$$/promotions when it goes right. Got to play the game a bit better.

I'm actually well-compensated in the parameters of this company (def. not enough to keep me from searching somewhere else).

The blame thing is more of a game than anything. Of course, I'm given all of the credit and way more than I really deserve. I uphold a certain outward image, but there is some understood amount of fiction.

For promotions. Well, the only way I'd be named "manager" is if I usurp another manager, but there is no one I'd want to usurp. I'm deeply involved in every department, so what would I be a manager of? I am basically manager of everything involving X, Y, and Z, and I'm okay lingering in the background. It's more of an understood position and not a bequeathed position. I've heard it more than once: "What exactly do you do here, anyways?"

I don't care about titles. I just want to get **** done.

Suzzer, with your experience and languages I would 100% disagree with the idea that you'll have a hard time getting a good job in the next 10 years. And I'd heavily bet against anyone making that claim for the rest of your career, but obviously things are hard to know that far out.

In terms of getting out of coding, that's certainly true but I don't think it applies in a 1-2 year timeframe. And that should be enough for you to figure out if you like it or not. Plenty of people have gone back to a coding role after management explaining that they just like coding more.

Personally I quite like technical management when at a good company that does it right. Being able to get up to speed on a technical problem quickly to provide useful feedback is a pretty fun challenge.

On the topic of management:

There are, broadly speaking, four types of management tasks when it comes to software development. In small companies and/or small technical teams, they aren't necessarily distinguished, but in large companies/teams, these can be unrelated roles, even though the nature of software development is that they cannot be completely separated.

1. Technical leadership. Choosing technologies, designing the system at the big picture level, making other high-level technical decisions, performing code reviews, deciding on technical conventions, mentoring junior devs, advising executive management on technical matters. This is what architects, lead devs or principal engineers do.

2. Project/product management. Gathering requirements, understanding the domain and customers' needs, coordinating with various parties to decide on what to make on what schedule. At modern software companies, people in this role are not considered managers and certainly not automatically senior to developers. The less important quality is and the more important cost minimization is, the more important and senior this role is in relation to software development.

3. People management. Hiring, firing and evaluating employees, negotiating compensation, deciding on their roles, providing support, approving vacation requests, etc. When people say "management" without any qualifications, this is what they are talking about. If you write down what people managers do, it sounds trivial but the fact that they control money makes them important.

4. Executive management. Making strategic decisions at the whole company level (or division or whatever makes sense, in some cases)

If you take the money out of the equation, I think most developer types would rank these four roles in the following order: 4 > 1 > 2 > 3. But it's usually impossible to get to 4 without 3 and in many situations, you can't be a true 1 either without 3, because your manager will often override your decision. Also, 3 pays better than 1 or 2 at the same level for the same reason that bankers make more money than teachers - it's your job to deal with money. On the other hand, if 3 is pretty much you entire job, you are a middle manager without any real authority or independence and your career ceiling is low and risk is high.

If I were at a large software company, I'd look for the 1/3 type of position, while using 3 mostly as a lever to further myself as a 1, with an eye towards 4, depending on my level of ambition.

Great post. The 1/3 is definitely the role I imagine for a 'good' jump up into management for a developer.

I agree with this comoletely.

It seems completely absurd to me to think Suzzer would ever not be able to have a job like his now.

It seems like there are probably tens of thousands (hundreds?, more?) of jobs that are looking for basically an exact match of his experience right now.

I wouldn't worry about being out of programming for a couple years either. As long as the job market is this good, if you have the ability, you'll be able to find work.

Yeah I don't think you really ever forget how to program. You might forget some syntax and other small things but you can always look that stuff up, and other language specific things will come back to you pretty quickly.

very well said.

LOL.

My job is to put out fires and make sure half the company doesn't get shut down. I wish I was joking.

You should make this a priority for your future jobs imo. If possible I try to surround myself with coworkers that have interesting skillsets and I mae sure I'm not the smartest person in the room (by a good margin).
Also I hate being around *******s. Not getting along really well with coworkers is an instaquit no qestions asked situation for me.

Edit:
Regarding management. Since I have executive level management experience according to my CV here's what I did: I did all the stuff in a small software company that the developers didn't want to do. There was the CEO who was a hacker at heart and when he wasn't hacking away he was the guy customers wanted to talk to (+he did lobbying against patents and for free software), there's was the VP sales who basically handled all accounts and was a boss (also good programmer, scripted a bunch of repetitve tasks etc.), an accountant to handle all the legally-numbery stuff (laywyers outsourced). I programmed as much as I could but every minute I spent talking to customers, working on overall strategy, doing legally required project management stuff, taking meetings for the CEO, negotiating contracts, hireing people etc. was +EV because our programmers were so smart. I might have prefered to program 100% of the time (not sure though) but if there's guys that are 20x more efficient (my guestimate)...why? I happen to also enjoy all things business as well.

I also think that at a technology driven company of small enough size everyone doing any management work needs to be very humble. Alas that's not really a mindset you tend to pick up as a freshly minted MBA.

Anyone ever used these guys?

http://www.saylor.org/pathways/full-curricula/#CS

I'm thinking about going through some of the courses that I either didn't take as electives in school or that I want to brush up on.

I have a 3 hour face-to-face coming up. I'm not sure if I should feel nervous or excited...

But yes, hoping to find a decent group of people and look forward to being the company idiot.

I'm still unlikely to want to go have dinner and beer with them. I don't think I've ever hung out with my coworkers aside from a few rare occasions. I mean, a skiing trip or Sunday BBQ at the beach on would be kind of scary, I fear. I sort of like to keep my life separated from work. I don't plan to find my wife on the job.

I'm kind of turned off when I see a job ad listing that says "we work hard and party harder. Our coworkers aren't just good friends, we are family" followed by a long list of "awesome **** we do together." I guess it indicates a lack of "cultural fit."

It is totally fine to have separation from work and personal life, and completely possible to be a great cultural fit and still not want to ever use your weekends/ nights to hang out with work people.

anyone else still find html5 video buggy? could it be because I'm on a linux desktop?

I agree. But if you're work culture is doing a lot of happy hours (mostly no weekends), and your work gets hectic and chaotic at times - those after hours bonding sessions with your team members make a big difference come crunch time imo.

Oh yea, I mean personally when that was the thing I was usually present at every after work drinking event.

There were definitely some people who were no-shows or rarely-show that still were completely cool in the office and great co-workers.

My interview went eh...

Writing on a whiteboard is surprisingly difficult. I managed to get all of the answers correct... I needed a little help with some syntax issues I'm not aware of, but overall, the concepts were correct. I feel like it was well-ran and I enjoyed that part of it quite a bit, even though my nerves were on edge and I probably came across as a scatterbrain.

The after-talk was a little bit of a struggle for me. This, incidentally, is where I have extreme difficulty as an interviewer and an interviewee. Do you have any questions for us? Ummm...

There was some mumble about "we'll have to discuss cultural fit" that kind of indicates to me that I didn't get the job.