On Transitioning from Software Developer to Architect

Around 2003 I changed companies and accepted the title “Software Architect” at the new company. Before that, I’d been working as a developer, then lead developer, then development team lead for a B2C startup.

If I had a time machine and could go back in time to give myself advice, this is what I would say.

Caveat: Unlike “Software Developer” or “Software Engineer”, pretty much each company has its own definition of what a “Software Architect” is. At one company I worked at, architects were solely concerned with deciding on which version of Java to use, and so on. But for me, and for this company I joined, and thus this advice, architecture was concerned with talking to requirements engineers and formulating a plan for delivering software projects. Not only deciding on the “stack” but also: database design, planning out classes/methods where necessary, certainly designing communication between modules, splitting the work into work packages for individual developers to do, code review, listening to the developers and adjusting the plan as necessary, and so on.

Avoid Becoming a Pure Architect

It just not possible to get deep knowledge about a new technology without using it in the real world. Reading books, articles, doing small POCs, etc., doesn’t cut it.

Recently I spent 5 weeks doing development with React. In React you can use “class-style” or “functional-style”. I spent ages reading articles about which I should choose. I went with “functional-style”. Only now do I see the real disadvantages of that style. Only after I’d worked with it, day-in-day-out for a while.

My solution, since that fateful job in 2005, was to avoid becoming a “pure architect”. You have to spend some % of your time doing development. Not just proof-of-concepts but a real contribution to the codebase which will get deployed and used, so you can see the real consequences of your decisions and understand what everyone else’s going through.

Be Aware of Manager’s vs Maker’s Schedule

Manager’s vs Maker’s Schedule in this nice article by Paul Graham.

If you’re just doing management it’s OK. If you’re just doing coding it’s OK. But mixing the two is a nightmare. If you do some coding, yet also take meetings with stakeholders etc., you’ll have to mix the two, I never found a way to get that to work well.

My solution was just to reject meetings as much as possible. Try to convert as much as possible to email.

That’s easier when you have a customer who understands the need to get into a “flow” when coding, than when there are n departments and people never coded so they don’t understand the maker’s schedule. Maybe try to block off half days on your calendar so you don’t get any meetings sent. It won’t be easy.

Try to avoid Slack as well. Slack is like a constant meeting. Being interrupted the whole time, you’ll never get any deep work done. I just close the email and Slack tabs while I’m doing deep work. I’m back an hour or two later, and people just live with that fine in my experience.

You’ll Be Working with People Who Know Even Less about Tech than the Current People You Work With

You have to be OK with that. I enjoy explaining tech to non-tech people. You have to want that. If not, being an architect might not be for you.

Get Developers on Your Side

Once, having completed a software design for a new system, we were ready to implement. The developers constantly said they’d start “in a few weeks”. But they never did. This went on for months. If you are responsible for a project, you have to have the confirmation that the development resources are committed. Otherwise, nothing will get done, and it might end up looking like it’s your fault.

You need to have the devs on your side. Explain to them the advantages in terms of problems they’re having now (e.g. how their workload will get easier), and/or take them out for beers, and so on.

People Will Be Jealous of Your Tech Knowledge and They Will Try to Sabotage You

Not all architects were coders beforehand (which is madness, but a reality). Other architects have got a cushy well-paid job where they freely confuse Java and JavaScript. Then you come along. You were a dev. They won’t be happy about that. They will feel their jobs are in danger (perhaps rightly). They’ll try to sabotage you.

Maybe compliment them regularly about the non-tech skills they do bring to the table. At least be on the look-out for this sort of stuff.

Appearances Matter (Unfortunately)

The people who decide if you get a promotion will not understand what you do. But it’s their job to judge you anyway. They cannot judge you on the code quality your developers produce using your architectures, because they don’t understand that.

They can only judge you on things they do understand.

Things like punctuality for meetings, appearing prepared/organized for meetings, and so on. You’re going to have to do all this stuff even though, at least sometimes, you know it’s irrelevant.

Be Aware People Will Deliberately Withhold Information

In a “professional” company. Really! It’s madness.

I went with a salesperson to a potential customer. I told the customer we could integrate system X and system Y, but it would take a while to implement. The salesperson asked me afterwards why I’d said that, as he knew for certain the software to integrate the systems had already been developed. When I was back at the office, I asked around, one project manager proudly told me “if we’d have told you, you’d have told this other guy in the company, and we didn’t want him to know”.

If you work for a company where people are not even hiding the fact they’re working for their fiefdoms instead of the goals of the company, you’ll never do great work there. Life is too short. Leave immediately.

Read Every Git Commit

At least read the commit message, and who did it, but ideally scan the code diff as well.

Set up your central Git server to send you emails any time anyone pushes to any branch.

Even commits by people who aren’t directly working with you. You need to know what’s going on. My father used to work with a CEO of a few-hundred-employee company in the early 90s. This CEO read every fax that went out or in of his company. He reckoned employees could massage the truth, but the faxes told him what was really going on. Reading “git commits” is the modern equivalent.

That also implies: push back on people who commit huge diffs full of whitespace changes, or commit 20 files full of various changes with the message “improvements”, or anything which makes that job more difficult.

Enforce a rule that everyone should commit at least once a day. If they’re unhappy with that “but the work isn’t finished!” then, good news, you’re using Git, where branches are cheap, so they should just create a branch and push that.

Keep on Top of the Schedule and Budget

It may not be 100% your job, but it’s good to have an up-to-date idea of what the open tasks are, and if you’ll meet the deadline and budget constraints. You’ll be more useful to your non-technical superiors if you take care of that.

I used to use LiquidPlanner. Others use MS Project. No doubt there are many other ways to do it. At least keep a spreadsheet where you track the major work packages and their estimated days left, to give you a rough feeling if you are basically on track or not (but that implies asking the developers where they are which is an overhead; so a tool where they can enter that data themselves might be useful after all, then again they might just ignore your tool). But you need something.

You don’t want to run a 6-month project with a bunch of people, then 2 days before the deadline, realize, OK, nothing is finished, we did some non-essential tasks in the past and now don’t have time for essential tasks or to train anyone to help us out.

Somehow—it doesn’t matter how—you need to avoid that. You need to know the stuff is going to go wrong as soon as possible.

The sooner you know, the more you can do about it. For example, adding a developer to a project a few weeks before the deadline slows the project down as your productive team-members have to train the new person. But adding them 6 months in advance is a win.

You might think “but I can’t possibly know what bugs or other issues are going to take longer than planned” or “you can’t estimate software”. That’s not true. You might not know the future with 100% accuracy, but it’s not true you know nothing either. Don’t let “perfect be the enemy of good”.

What I have found, is that if you estimate a project will be completed by date X, it might be delivered after date X due to slippage, but I have yet to encounter a project which was delivered before date X. So, if date X is already beyond the deadline, you can safely take action now, to rescue your project.

“Rockstar Architect” Isn’t a Thing

You know you’re a “10x developer”. You can get away with turning up late to meetings, persuading the boss to let you fly while everyone else has to take the train (true story), etc. In short, you’re a diva.

Bad news: that won’t work as an architect. You need to get out of that habit. See “Appearances Matter” above.

I think the reason is: management often has a vague unscientific awareness of “If I give this task to developer X it gets done well. If I give it to Y it takes weeks and has a bunch of bugs”. It’s much more difficult to judge the output of an architect.

But You Should Still Do It :)

I still think it’s worth going for an architect position. You have more control over the projects you work on. You get closer to the requirements engineers and discover why you’re working on the things you’re working on. You get closer to the business (money) side of things (e.g. accompany salespeople to prospective clients).

But just be aware of the traps.

Let me know your experiences when you became an architect in the comments.