Slashdot Mirror
Coder or Architect?
camusflage queries: "I recently was transitioned into an architectural role by my employer. I had been splitting time with development and architecture, in that order. It appears my new duties put me as an architect first, and a coder second, with the coding being at my request. At not even 28 years old, I'm already a lead developer and have people with twenty years more experience looking to me for coding hints and tips. Over that past year with my employer, I've expended much effort on developing credible relationships with other groups in the organization, sure to carry me far as an architect. Since I've already resolved that management is not a track I want to get into, is architecture my most logical next step? What do I need to do to make sure my skills still remain sharp, as I'll be spending less time in the bits and bytes? Any tips from those who have made the transition from development to architecture (both successfully and unsuccessfully) are appreciated."
You cannot be an architect unless you also implement, since it's impossible to design the architecture unless you know what happens inside the software. And you cannot get this knowledge without participating in the implementation. Therefore, there is no problem. The only thing is, there are higher hopes for you (in addition to the ordinary requirements for coders, you are also expected to actually design the system!) It's just more responsibility. Nothing else changes!. See the Architect also implements (http://www.bell-labs.com/user/cope/Patterns/Proce ss/section16.html) software process pattern for a detailed overview.
-- Esa Pulkkinen
Being your same age and in a similar role for 4-5 years, I'd say the following:
1) Going from team developer to architect/lead means that you're going to have to de-specialize. There will now be people who know more than you do about specific things, and not only is that inevitable, it's _required_ in order for you to be able to build larger and larger projects. There's a big humility bump to get over when you first realize this. Deal with it.
2) As an earlier poster said, you're likely to become a translation engine between your development team and other organizations inside and outside your department/company. My job nowadays is as much marketing/product management as it is engineering, but that doesn't mean I've sold out. It means I can do more good for the company as a whole architecting solutions in the holistic space rather than as a disjoint entity.
3) Coding -- you'll say now 'I want to keep coding' but this will be hard. NEVER let yourself be sole lead on a coding project -- instead become special ops for key projects where a little additional oomph is needed, or do prototype code when something's needed in a hurry, but ALWAYS hand it off to someone else to be the long-term owner. Otherwise you'll never advance.
4) Make yourself visible inside and outside of engineering, but not to the exclusion of others. You will be seen as the gateway by pure coders in your team, and make sure that you give them full credit for what they do. By doing so you'll be giving yourself credit, too.
5) Don't run off and get an MBA, but do learn about team and time management, and development cycles. Read 'The Mythical Man Month' if you haven't already. If you have read it already, read it again. Then buy several copies and hand them out to the next non-engineers who come and ask you for something.
6) Remember that who you are hasn't changed, and that the people you work with, not you, are still your greatest assets!
I learned all this the hard way!
Be prepared to spend a lot more time researching
and reading and talking about strategic decisions.
Being an architect means that while you need to
make tactical decisions on an on-going
basis, you do need to spend a considerable amount
of time to look at the long term aspects of
projects and worry about how things will come
together, where you want to end up etc.
You can also expect to be less and less hands-on.
And that's where perhaps the biggest challenge
lies: You need to keep up and be sharp on not
just today's stuff, but just as much the many
tomorrows and potentials and try to make decision
today that set the right direction.
It can be a quite daunting task depending on how
quickly your area is evolving. How do you stay
up on the details, while not getting lost in
them, and know enough to make (or prepare) key
strategic decisions without having the same
hands-on exposure as you have when in the
trenches.
So, expect to spend a third if not two thirds of
your time on strategic work, reading, talking to
people, brainstorming, participating in industry
forums, whatever is suitable for your specific
niche (and even that's not a proper term for
architects as you really need to look and think
outside the box).
Simply leading others doesn't make you an
architect. Architects are visionaries for the
company, and in addition to technical and
political prowess, you should also posses a good
bit of entrepreneurial spirit. Those are key
ingredients to making sound architectural
decisions.
Because you'll have less hands-on, you'll also
need to become quite skilled in dealing with the
people who are in the trenches. You need to
develop a network of people, develop people skills
to work with others to glean experience and
knowledge without neccessarily directly working
with products. Yet, unlike your general (bit
perhaps some technical) manager, you need to be
able to have the skills, people and technical, to
interact with others and sort out fact from
fiction.
Architects need to have a sound understanding of
the business itself. Many decisions you make as
an architect are in liason roles: You serve as
the joint between the technical guys in the
trenches and management on the other side. You
need to communicate well with either. The
techies will want you to make sound decisions to
not make their life any more hell than it
already is, and the manglers will want sound
business decisions (which includes politics,
finance, technical etc etc).
Don't be afraid, just do it :^).. we all learn
every day as we go.
True architects do not really have managerial
responsibilities if they are supposed to have
time to do all the other things they have to do
to explore all the 10 choices of which you're
going to chose one, and of which 9 are a waste
of time at the end.
Getting management to understand that a lot of
an architects tasks (time wise) don't neccessarily
yield results is crucial.
And ditto for the techies who'll wonder why you're
wandering off chasing a tangent you find
important but that is beyond their tactical
horizon.
Hope this helps.. Good luck.
Poof.
My 2 cents ...
... thats a full time job.
.... focus on what's inportant for the role you are playing, and let your talented software engineers play their role.
An architect can sometimes be though of as a technical organizer.
It's a role more than a position. An architect steps in when you have a group of developers and you need to get from point A to point B with as little risk as possible (technical and/or otherwise.) You should take into account business goals, technical skillset, marketing requests, and supportability.
One you and your team have layed out the architecure, and aligned it with the various business goals, there is nothing wrong with you taking a *minor* programming task, assuming you have time.
But also realize that architects play by differnt rules than coders. Your skillset in dealing with groups of technical AND non-technical people will be more important that your skillset in a particual language. Your ability to leverage the your companies talented programming staff to produce someting everyone is proud of (and also happens to be on-time and under budget) will be the what you are measured by. Making sure you have an architecure that can adapt you the changing needs of your business
You'll really hurt yourself if you try to be a General and an Elite Commando at the same time
You should check out Norm Matloff's Debunking the Myth of a Software Labor Shortage . In a few more years, you probably will want to transition into a lead design or managerial role, so this track is reasonable (especially if you want to become say CTO of some firm during the next upswing in the tech sector).
There have been several remarks say that you should continue to code. It is probably not a bad idea to continue coding, however, being a good leader/manager DOES NOT mean that you need to be a great coder. It helps to win the engineer's respect, but if you follow sports, you know that the best coaches were not necessarily great athletes in the sports they coach (e.g. Bela Karolyi in Women's Gymnastics) but they do have to understand both their people and the jobs that they do.
The most important thing is to ride out this current weakness in the economy and position yourself for a profitable and successful ride in the upswing. Don't get trapped into obscure or uninteresting technologies by chasing short term rewards.
"Special" is one of those marvelous adjectives used in weasel-mode, when you don't want to actually say what you mean:
Special Projects
Special Education
Special Forces
Special Prosecuter
Special Interests
Special Olympics
Special Effects
Special Weapons and Tactics
It's not *always* perjorative...that depends mostly on how you felt about the ordinary, "unspecial" stuff.
"Isn't *that* special!" --The Church Lady
-=Maggie Leber=-
Sooner or later a project will hit crisis. Since the heaviest load of architectural work (for an even moderately well-planned project) is near the beginning, and the crisis point for most projects is near the end, you can keep your skills up just by involving yourself in the crisis coding near the end of projects.
:)
Of course, it's always possible that your development organization never has crises, but if that's the case then you are so blessed by the deities of programming that you will never need to worry about code anyway
--G
Or your post could be read...
/. where tons of people will read my reply and think the exact same thing I did and mod me up."
"I am a whining loser that can't find a job and I am going to bitch about it on
Then they will sit there and think to themselves, "I just wasted +1 on this fool."
Honestly, I am happy for the guy and I could see him seriously asking this question only for feedback from the largest group of online people in his field.
Go back and cry to yourself, not to us.
Remember that architects work for developers. If an architect doesn't make the developer's job easier or successful, then the architect has failed. If that includes answering some questions from time to time, that's all part of the job. You've just moved your fate from your hands into the hands of your developers.
;)
Same it true for managers. Sometimes it's easy to forget that and become the architect/manager that causes the downfall of a project. A wise man once said, there are no stupid soldiers, only stupid generals.
Just make sure your career path is the path to success not a setup for blame and humiliation by the people with 20 years more experience who know that the project isn't viable in either a technical or business sense. Keep in mind, you don't stay employed for 25 years and not learn to steer clear from icebergs...
Now isn't that cynical
I had expected to code like that until I retired to the beach, which I hoped would be long before I was 30. As it turned out however I found that my concentration had gone long before I was 30.
I can still lay out a set of APIs, document them and describe in detail how each code module connects to each other. But I just don't have the patience to fill in the boxes any more.
The only coding I have done in the past few years has been of the explortory type, working out how the new .NET tools work, doing my own technical drawing template in Visio etc.
At 28 it would not be at all surprising if you are over the hill for coding. But that does not mean that you are necessarily up to being an architect. In my experience less than one coder in 10 ever has the breadth of experience necessary to make them a passably good aarchitect. Being 'lead developer' for you 'company' means nothing to me, dotcom startups are still ten a penny. All being a lead developer means is that management thinks the sun shines out of your ass, or to be more precise management thinks the probability of the sun shining out of your ass is slightly higher than the same probability for the other candidates they could find after their last lead developer went to get a better job.
Being a coder is a useful attribute for an architect, however many of the most productive coders make the worst architects. A lot of highly productive coders are only expert in a single tool. Every problem looks to them to demand its use. They spend their time trying to get their coders to code like them thinking that it is the tools themselves not their particular level of expertise with one tool that made them productive.
I recently spent some time in a working group where one faction made a demand that the spec be documented using a 'graphical notation'. This faction then spent some considerable time trying to represent XML schemas with entity relationship diagrams, an utterly clueless and futile project that was based on the ridiculous belief that entity relationship models are the one true data model. Pity they haven't noticed that none of the mainstream programming languages developed in the last ten years is based on that data model or that XML schema in particular is utterly incompatible.
Coding is a very different skill from writing a specification. To be an architect you have to be able to do the requirements analysis yourself. You also have to be able to reverse engineer the actual requirements from the design that the end users will give you since if they could write a spec they would not be end users they would be architects.
You also have to actualy be interested in the larger purposes of the application, the business it serves and the business strategy that the application serves.
Good architects are rare. Great architects are exceptionaly rare.
Look at the World Wide Web, hundreds of network hypertext projects preceeded it, every one of which failed because it was just too damn complex.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
I've worked at a company developing a quite-known operation system. I know about several components performing the same task, yet are duplicated. The OS in question is targetted at embedded system (in a way) which makes it even worse.
That's a good start for "code deletion"
it's in my head
I love the following quote from BredeMeyer Consulting:
"Too frequently, "architect" is a promotion offered to top-notch developers in an effort to retain them. Unfortunately not all superb technologists have the broader talents and skills that make them good architects. Still, the title raises expectations in the "architect"--and the rest of the organization--that architectural responsibilities are associated with the titled position.
This can generate a lot of conflict for a strongly technically-oriented person who is suddenly overwhelmed with organizational politics and communication demands."
The only thing that I'd add to this is: if you have an excellent developer who you stand to lose, try creating a surgeon team around her. I first read about this technique in "Mythical Man Month" and used it with one of my "gun" developers. He didn't want to manage or even mentor staff. But he just wasn't productive enough on his own because he still needed to do unit testing and requirements work etc.
So I created a surgical team of 7 people who "supported him" (the surgeon) doing requriements updates, testing, backup dev and project management. I know this sounds stupid, but it worked really well... everybody knew their place: working FOR him. But not reporting TO him.
We launched 3 successful projects in that fashion.
Patrick.
I'm going to make one modification here. Basically what I said above is that I can't see that anything anyone does is more important than writing the code. However, let me amend that -- the only thing that I can see as being more important than writing the code is TEACHING other people in your company the stuff you know. I really thing that the ideal software company would be completely non-heirarchical, a totally flat structure where absolutely everyone's first job is to write code. Sure, that's total idealistic nonsense, but that's why I post these things on slashdot instead of getting myself fired by talking about them at work.
Get used to the idea that as an architect you will no longer be able to measure your productivity in terms of lines of code or any similar "objective" measure. When I first started getting more involved in architect-level activities, I saw that my productivity as a coder was declining and I was quite distraught. It took me a long time to reconcile myself to the idea that code was no longer my main contribution, and that I had to find more flexible ways to determine whether I was functioning optimally. This is also a time-management problem, as you become less able to use checkin trails etc. to keep yourself on schedule.
Accept that you cannot escape your responsibility to be a leader, mentor, etc. Think of yourself as a high-level NCO on the battlefield. You're not an officer making command decisions and you're not some paper-pusher who never picked up a gun; those are the executives and managers respectively. Instead, you're in the foxholes with the grunts, fighting the same war they are. Your leadership consists of communicating basic skills and priorities, managing morale and discipline, acting as an advocate, and generally setting a good example. If you're not comfortable doing all of these things, find a different role, perhaps one that concentrates more on specialized technical skills, because nobody is more universally loathed - by superiors, peers, and more junior team members - than a tech lead or architect who doesn't help to "stiffen the backbone" of the organization.
In a similar vein, your new position makes you a target for the climbers and backstabbers in your company. Everything you say will travel further and carry more weight than it did before, with potentially disastrous consequences if you're not careful. A grunt can say almost anything because, basically, nobody will really notice or care. When you're an architect that's not the case. I know it seems political, but it pays to develop "situational awareness" of who you're talking to, what their agendas are, who they're likely to repeat your words to, etc. It's distasteful, but if you want your people or your projects or your principles to prevail then you have to avoid traps and ambushes.
Slashdot - News for Herds. Stuff that Splatters.