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."
Make sure that your work is visible though, i.e, be prepared to show that your chosen architectures and the directions you've had the projects take are the successful ones. Management has some problems sometimes with people not producing x lines of code each day
it's in my head
Given the fact that you seem unable to resolve key personal issues using your own judgement, I would have to say you are certainly not ready to make those decisions for others. Stay coding.
After 20 years in the computer industry, I pitch myself as a Systems Architect. If someone doesn't understand what that is, I simply explain:
Analysis
Design
Development
Implementation
Education
All fall under the realm of any decent architect. Nothing was ever built without a little of all of the above, well applied, and when needed.
Stay on top of the tools, keep your finger on the pulse of the brick and mortar materials science realm of the industry.
But always wear the hat of the architect, even when you're doing something as humble writing code.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
High-level engineers are often depended on by managers above them to translate engineering concepts. This can drive you nuts as you realize how little some managers know.
Worse yet though is how with little effort you will be dragged into meetings and conference calls until your schedule is booked. Don't let this happen. Have a open and strong relationship with whoever you report to that allows you (or them) to say "no" to new commitments.
Evan - needs to hit preview before submitting
I moved from developer to architect/developer and then into manager/architect/devleoper. There's no doubt that between the three jobs, I find it very hard to do any single one completely. I've been fortunate to have a really great team who I now share the management and architect duties with. I still have the final say on architecture, as I designed the flagship product for our company, but I'm very open to ideas and fortunately have very talented people working with me.
The key to keeping your skills sharp, though is to keep writing software. Not just as a hobby, but as part of your job. Find the time to do it, somehow. If you lose that skill, you're in a position where you could lose your ability to effectively architect and manage (assuming you ever do that as well). My advantage is my roots as a developer and the fact that I maintain it. My best managers in the past were technically proficient and understood problems I was facing, and I could explain it to them in my language. If you lose that, you lose that effectiveness.
This is just my opinion, but it's based on my past exerpience as a deveoper and my current experience as manager/architect/developer.
It's definitely a lot more work than it used to be, but it's also a lot more rewarding. If it wasn't, I'd go back to just being a developer.
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
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.
It makes you sound like a real asshole.
The only way to keep your skills sharp is to keep coding. "Pure" architects, the ones who only write edicts from an ivory tower tend not to keep their skills for one simple reason: problems do not normally reside in architecture but implementation (you really pick up on problems in implementation). So you could always work on home projects.
:) )
The second option is to push for a method like XP (Extreme programming) in which everybody codes (in pairs). This allows for your skill (the coding skill that got you your promotion) to be transmitted to other members in the team and to the project you'll be working on. Who knows, you may pair up with a kid out of college who'll teach you a thing or two about coding or ressource management.
Lastly, a rant: why do organizations try to push techies out of the jobs that they do well ? I've seen a gazillion good coders move into management jobs and just Peter Principle out. I've seen good coders move into architecting jobs and all of a sudden lose perspective on the goal of system developpement: deliver a system.
Why is going into architecture or management a promotion ? Shouldn't it be a skill ?
JP Belanger (just a programmer
jpbelang at eloas dot qc dot ca
JP http://www.wearerite.com
Stop getting your hair cut for a while. Then, when it is long enough, get it shaved down the middle and apply mousse to fashion the remaining hair into two pointy shapes.
--
Mod up a post Rob doesn't like and you'll never mod again
Well having gone through coder, architect, consultant contract, CTO, Developer Manager, etc there are a couple things I have learned. Like yourself I am not too old (33). First figure out what you really like. That is the most important factor. If your do not like what you do you will do it ok, but not outstanding.
What I figured out is that I love to advise other people what to do. In other words I love being a consultant / architect / mentor. But in that field you need to stay on top of things. The best way to stay on top of things is to simply read, write and just do what you love. Just doing things at work will not give you that edge. Socialize, attend conferences, write articles. Become involved.
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
"Special Projects"? :) Didn't another poster mention that Special Projects is a euphemism for "We don't have the heart to fire you"?
/.
This is not a slur against you or your skills, and that company could have used entirely different naming conventions, but I found it quite surprising that that term was used in two different contexts within a few days of each other on
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
I had the same dilemma -- I have over a decade of experience, but didn't want to get to far away from the code by taking the management OR architect routes. I had experience with both paths, and although I was labeled a success by subordinates and peers I just wasn't enjoying work as much as I did when I was coding.
:)
Then I was exposed to Extreme Programming, and I haven't looked back since. It manages to offload many management bottlenecks by introducing social forces that have made us the most successful animal since ancient times into the equation. At the same time, it unburdens you from the "architect in the ivory tower" syndrome which isolates so many formerly valuable coders. This allows you to take a title of manager or architect if it is forced on you or is the best path towards career growth (i.e. "more money"), but in reality utilize XP to stay true to your coding roots. Just remember, without code, architects and managers are *totally useless* -- its really that simple
If you like working for small, agile companies and winning teams than XP is a great path. If you prefer big, bureaucratic monoliths or are too close minded to consider better ways of working with truly intelligent people than XP probably isn't for you. XP does take intelligent, hard working people so if you work with a bunch of posers don't even bother trying it as it is people-based (what isn't, really?) so it just takes 1-2 bad apples to spoil the team. Just wait until the tech sector improves and find a better company (or fire those losers if you have the power, since now is the best time in a long time to hire top notch people!).
I started an XP user group last year and since then have met 400+ of the best people my local tech community has to offer.
You're already on that track. You may no realize it yet, but you are.
After all, you will be directing (perhaps indirectly) how many people will be spending their efforts.
My advise, hone your people skills -- the higher you go the fewer and fewer people you will deal with who will 'just see the technically correct answer' -- you'll have to see things from their point of view and then convince either them (or yourself) of the correct answer. :)
Oh yeah, and the advice about being wary of meetings eating your time is good too...
Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra
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!
They cling to the notions that experience should be subborned to genius, with the provision that they be recognized as such.
There's a deep inherent smugness around here, but as Chuck wrote in Fight Club - You aren't special. You aren't a precious little snowflake.
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.
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.
Experience != Specific skills in every area. In other words someone with 20 years of experience still might be coming to you for VB help because he specializes in C++ and doesn't ever want to become a VB expert. I just had a problem with the idea that it's an indication of genius because coworkers call upon your skills in certain areas: that's the idea behind teamwork.
Note that I'm not saying this as a grizzled veteran trying to defend the value of my experience: I'm around the same age, and am often in the same situation (i.e. used as a resource), but every now and then I realize that it might be more that I end up being a sucker than any inherent genius (i.e. if people know that they can ask you and you'll hunt around like a gopher to have the answers for them, pretty soon they'll get lazy and start using you in that respect).
For what it's worth, I faced the same issue as my career migrated into management. The more I advanced, the less hands-on I could be. That didn't work for me; not only do I enjoy the hands-on work, I've always felt that management is more effective when it has some idea of what it is managing.
My solution is to moonlight as a free-lance consultant. I focus mostly on small, privately-owned companies that need solid expertise, but don't need 40 hours per week and can't afford $200 per hour. I establish a base rate of $150 per hour, just to place myself in the market, then discount it sharply to what the companies can afford. They understand up front that my work is almost exclusively after-hours. In return, they get a big discount.
I mostly rely on word-of-mouth for business. These business owners do talk to each other, and they'll enthusiastically recommend someone who gives good service. I also let local vendors know what I do, not your CompUSAs necessarily, but local branches of business systems (e.g., Sun, IBM). They often have customers who need a hand, but can't afford their big project rate structure. I'm not a threat, since I will not and cannot commit to anything that takes major manpower.
I've been doing this for 15 years or so. It keeps me hands-on. It's also a great source of extra income, pays for the tech "toys" I use in my business. In the process, I had to learn a lot more about running a business - tax and financial issues in particular - which is valuable in my real job.
My only caveat, be realistic about how much time you can spend over the long term. It's fun at first, but the novelty wears off. It gets to be work, especially when the weather's nice or there's a new example of your favorite addiction (games, sports, books, whatever). Your clients depend on you. If you leave them hanging, you can hurt their business.
That's a great combination of fields, coder and architect! You can write CAD software for designing buildings, or figure out exactly how to run your UTP cables, or position the windows so you don't have reflections off your monitors...
Huh?
A *SOFTWARE* architect?
Oh. Never mind.
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.
He's 28 and he hasn't retired yet. Loser.
The good and new comes from no quarter where it is looked for, and is always something different from what is expected.
"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=-
Things I'd recommend (being 28 and in the same position myself):
1) Leave any arrogance you have at the door. People 20 years older than you may not have your raw talent, but they have a lot of wisdom we 20-somethings don't have yet. Arrogance is a sure way to draw resentment from your seniors.
2) There's nothing wrong with unscalability when scalability is not an issue. For example, don't bother architecting your Web application to scale to millions of users when your target audience is only a dozen. New architects tend to overkill every solution.
3) Don't get religious over OS, dev tools, etc. However, don't be too agnostic, either. If your shop is very Windows-based, don't try to revolutionize it with Linux - and vice versa.
4) Document, document, document. UML comes handy here.
5) Ask people about their concerns - just because you're the architect doesn't mean you have to be all-seeing. You just have to be smart enough to know who can help you identify and think through problem areas.
6) Prototype, prototype, prototype. Hack the code if you need to - it doesn't have to be pretty.
7) Architecture != Code Organization. Architecture can affect code organization, but it is a separate issue. Two projects with the same architecture can have completely different code structure. Don't get caught up with code organization. That's an issue to tackle later.
8) Read books about software architecture. It may seem beneath you, but it's definitely worth it. It certainly cannot hurt, and mainly it helps to cover your ass in case you need to defend your decisions. I've had to write memos to defend my design, and it's very easy to do when 3 or 4 famous books agree with you.
The first thing that ran through my mind after reading your post was "been there, done that" or at least I thought so at the time. Some of the best advice in response so far has been along the vein of "don't get cocky". It really doesn't take much to get that label of primma donna or 'difficult to work with' and it's damn hard to shake.
The economy is going to hell in a handbasket and some of the first people to go sound just like you. Fewer years of experience coupled with a higher hourly rate make a good target. I'm not saying it will happen, the odds just favor it. FYI, I'll grant you I might be biased as it just happened to me.
The longer your work on a system fixing problems, the more people come to you when they decide to alter it. It's a natural progression and no big deal.
It sounds like things are going well for you in the office. Keep doing what your doing and make sure you continue to produce results and that your happy doing the work. With those two things in mind, you can't fail.
Career direction doesn't matter until you come across the ideal job, and go "Wow! I want to DO THAT!!!" There is not a single person here that will be able your office, your environment, or what you will need to do there to succeed.
~~ What's stopping you?
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
Never totally stop coding.
In any project that is worth having a team and an architect, different parts of the code will fall on the spectrum between 'interesting' and performance/reliability critical all the way down to cut/paste boilerplate, code by numbers.
Assign or have assigned to yourself some part of the former code. This will help to keep your skills sharp as well as provide insight into the problems being faced by other members of the team. The tough part is deciding on how much code to do yourself. Taking too much will sap the time you should be spending on overall design, and will deprive other coders of the challenges needed to grow and remain interested in the job.
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.
What you see when you move from a more in depth position (network/systems/software engineer) to a more abstract position is a requirement to understand and deploy/spearhead solutions to solve business "problems". If you are lucky, you are a revenue stream and life is easy. If you are unlucky, you are eventually required to support Micro$oft products. (grin)
The basic priciples descibed for software engineering always apply, but it's my opinion that the cycle is much more fluid at a higher level. (More people to appease, more requirements to understand.)
Raw talent is good to have, but the soft skills to interface and move projects that invariably cross business units forward become quite important. Don't worry about offering specific advice to folks; they are prolly more interested in following the steps of a high riser. Make sure to keep adept at the technologies that made you successful (DBA/software/networking), but also try to consider solutions with different types of technologies.
Do things that make peoples jobs easier, look for patterns in problems, look for the same in solutions. Try to learn from people that have been there, use newgroups, discussion forums, friends to your advantage. Be good at being a leader; don't be afraid to say you fucked something up when it happens.
Take responsibilty.
--Adrian
As much as I wish I could assure you that you can be an architect for the rest of your career, from my own experience I have to advise you to do otherwise. Like many who are responding to this article, I, too, have been an architect.
;)
Currently, I work at a high-profile software start-up and guess what? No one has the official role of architect. We have a very experienced, very successful development and management team, too; apparently, they do not see granting someone the title "architect" to be beneficial to their success. For the trolls out there: the lack of an official architect will not be a reason a company like mine fails.
Others replying to your article have mentioned that it is important to like what you do. I concur, and that will always be the best compass for your career. But, having said that, I think the role of architect may indicate that you are currently in an anomalous position: chances are good you may merely be smarter or more capable of viewing the big picture than everyone around you. However, what if you were in a different company, or working on a different team? You may find that you are just barely keeping up. I contend that in a different environment, with others who may have skills to match or exceed your own, you may actually be more succesful as a developer than an architect. Therefore, don't pigeonhole yourself unnecessarily.
Further, nearly every successful architect that I have ever seen eventually succumbs to the need to become a manager. It's just part of the natural order of business: in a good company, those who lead and mentor need to become managers because they are best suited to tending to others, to steering the ship. That doesn't mean every manager is good as a leader or mentor (I've met my share of pointy-haired bosses, too), but invariably every good architect finds limits to their influence as an architect--and discovers that bearing a managerial title can actually increase their effectiveness.
Or consider another dimension: maybe it's not what role you should play (developer or architect or manager), but perhaps in what type of industry you work. Architects can often be much happier as a consultant, either for someone else's firm or their own; it is difficult to remain satisfied in a staid, old-line firm where 70% of the challenge is keeping ahead of maintenance.
Having only relatively recently passed through the same dilemma you face, I encourage you to understand the simplicity of the choices as you perceive them to be contextual. I, for example, chose to move on from a role as an architect and individual contributor, to accept a role as a director and department head because I understand that I had too many skills (such as a knowledge of the business, how to work with customers, and project management) that would have evaporated had I not made the transition. Of course, there are other skills I now have the chance to learn, too: how to *really* please customers, not just once, but on a regular basis; how to design an organization; how to architect systems for an entire company rather than for a single application; and (trickiest of all) to motivate, encourage, and develop the careers of my staff, especially when each one of them may have an inkling of their own desire to be an architect!
Ultimately, though, I did make my choice because I understand that I can apply the same skills that I honed as an architect (and many others I learned along the way, including some new ones), but on a much larger canvas. It would be a loss to yourself and to both your current and future companies if you only allowed yourself to be an architect. Strive for those positions that allow you to have a stronger impact, if you are really the right one to be making that impact. My decision to become a manager hasn't at all changed who I am or what I like to do. I still architect a great deal, frequently when my own architect is elsewhere deployed.
Remember: try to understand your dilemma may be contextual; that continuing to be happy about what you do is the best guide; and that you owe it your peers to impact your organization in a way commensurate with your actual skill. You are just at the beginning of your career: just wait till you see what happens next.
I'm a 40-something programmer with over 20 years experience. My last job was a dot-com with free soda and stuff, and the one before that had a foosball table. I don't know why but one place is out of business and the other one has laid off from 100 down to 20 or so, and is probably not going to make it because of the September 11th thing.
What I really miss about those places is working with talented young architects. I used to get lots of cool Javascript tips and hints from the 22-year old CTO but now I have to read O'Reilly books (blah). My experience is mainly with lame old-fashioned stuff no one uses anymore, like SQL and C, so I need to work with Extreme XP younger architects so I can understand Java and patterns and other new stuff I didn't learn in my PL/I class back in the 1970s.
Someday I want to be an architect, but mainly I get stuck doing lame requirements and specification work, and writing code. I'm pretty good at finishing programs the younger programmers start on when they get pulled off to something even more rad, or when they get stuck with some stupid detail from the old days when old people like me designed everything wrong.
Now I work at a boring monolith place where all they think about is profit. I don't know how, because almost everyone is old like me, and they are using old-fashioned stuff. We are looking at Linux and PHP and MySQL for a new web site but without an architect to tell us what to do we have to do all this testing and stuff--I keep saying I KNOW it works because I read it on slashdot, but there are programmers and managers even older than me that want to see prototypes before they commit their business to new tools. No wonder they couldn't cut it at a bitchin' dot-com!
Anyway if you decide to be an architect please email me so I can apply for a job and learn some of those hints and tips--I really want to learn Java but I keep getting confused by the CLASSPATH concept.
Good luck dude!
Old guy
P.S. A few years ago I worked with some younger guys who knew lots of C++ tricks, and they had "Wizard" and "Scientist" in their title. Is that like an architect? And after the Rogaine starts to work what kind of haircut should I have (or should I just leave it bald)? What about a goatee or some kind of unusual beard? Will that help?
I think this "I'm an X; being an X means I don't write code anymore." is a pure fucking invention. I myself am a consultant which means I am a gun for hire and I tell people what to do a lot, and I come up with the architecture, but brother let me tell you I write lots of code. One of the things I've learned after being a consultant is that 95% of jobs are not necessary, i.e., you could fire 95% of the people at an organization/project and end up with the same result. Here's the dirty little secret: as a society we invent jobs for people to do because "everybody gotta do something." Most people are fucking useless.
Marine Biologist.
-- Sigs are for losers
I suspect that you will find, as I did, that the principal new demand is for breadth as well as depth in your technical knowledge. I know lots of Unix and C-oriented development stuff plus some networking, but there is a gap between that and devising the complete architecture for a website exposing previously internal business processes of a company with millions of customers. Depending on the nature of your organisation and products, you may also need to know a bit about third-party products in various market segments (i.e. for this bit of functionality we drop in product X and allocate Y man-weeks of effort for configuration, interfacing, deployment and support, insteasd of coding that part ourselves)
Things I have found useful are
- Know what you don't know - and figure out where to go for the expertise (e.g. who makes the best SSL accelerator / load-balancing switches? - I don't know for sure but I know who to ask).
- Consider a range of options - you haven't really done the job of architectural design justice if you have only considered one main approach. Even if it is the right approach it's good to show that it's right by comparing it to alternatives you considered.
- Build/discover/create a peer group of software architects. With software development & bug hunting it often helps to explain the problem - sometimes you stop in the middle and go "aha!" and rush off because you have figured it out. Architecture can be very similar. Watch out for the look on your peer's face that says "Why are you doing it that way?" It might mean that you're barking up the wrong tree, but it also might mean that this element of the solution will have to be carefully explained to the client in terms of its advantages, otherwise they won't go for your proposal.
- Scope control - learn to negotiate the scope of the system. This was probably mostly out of your control as a developer, but as an architect this can be one of the most powerful tools you have. Tight/clever/detailed/thoughtful control over the scope of the system to be built can lead to great improvements in reliability or reductions in development time - i.e. push those stupid features that take 10x the effort for 10% of the benefit out of scope. The sales guys won't like it if you say "it's too hard" but they'll listen a lot better if you say "if we remove that from the scope we reduce the delivery risk (and hence the risk to the customer as well as us) and increase our profit margin". They like that wording a lot better. You may have to phrase it as "let's defer that until phase 2 because..." of course.
Because of the wider scope of your role (i.e. responsible for the design of the whole shooting match) you may find that you need to make decisions - in principle - about things which you would not have had to code yourself in your previous role. At least learn a bit about all that stuff. Depending on your role, this may mean learning more about middleware, distributed database architectures, wiring, user interfaces, credit vetting, image processing, or some other thing you don't already know about. Figure out what this is and who knows it.Undestand the capabilities of the developers who will write the code. This is important when considering multiple approaches. There is no point basing your system on J2EE if it has to be delivered in 3 months and nobody knows Java. However, you should always know when to break this rule - for example, if you have to transfer lots of files, use SCP or Perl's Net::FTP instead of coding it in C.
Sometimes you will need really detailed understanding of a specific thing. For example, there are things you just can't do reliably over NFS. Figure out what these potential pitfalls are.
Again depending on your role you may find that you need a bit of training in presentation skills, team leading, sales techniques, product selection in some market area, or various technical things that previously weren't your problem.
Talk to your peer architects. Which approaches worked, and which didn't? Why? Which bits are harder/more expensive than people normally realise?
Even junior programmers these days have to architect large systems because of poor leadership, mismanagement, and dead wood in the department. Its not suprising to see even the most junior underpaid programmers designing important components with no input from above. If this is part of the junior or entry-level requirements, then the compensation should reflect that, but it doesn't. And if the project fails in some way it's the newest, lowest paid guy's fault. If something goes right, PHBs and higher-ups try to take the credit.
Agree with the Code Free Software comment. - find an itch, then find a new way to scratch it (i.e. learn a new language/technique/whatever).
However, project design is NOT management. It is very definitely a technical role, and should be something most senior programmers see as part of their job. Even one-(wo)man projects need some design effort.
If you really want to succeed, you need to hone your technical skills, develop strong relationships within your organization/sphere, and also balance the line between "in charge" and "egomaniac" and "overly democratic". All this is really an exercise in wisdom. Learn when you can. Carefully apply what you've learned.
Stop the brainwash
I'm 28 and I think that I'm really awesome.
:)
This is great. I think I'm going to post it in my cubicle.
Seriously though, you know nothing about what I've done with my life/career. For all you know, I may have been freelancing since I was 12 (I have), I may have been working in IT since I was 16 (I have), and I may have been developing since I was 14 (again, I have). I don't claim to have the most knowledge (I don't), and I don't claim to have the most experience (again, I don't), but I do have the ability to see both the forest and the trees at the same time, which from my experience is pretty damn unique in the field.
The truth about Scientology, Xenu, and you: Operation Clambake
These especially apply for touchy-feely jobs like "information architecture," but can be applied to any job within McCorporation.
1. Clearly define yearly goals. Make sure they're realistic and qualitative, not quantitative. Include in your goals learning something you are interested in. Have your manager sign off on them.
2. Touch every project you know of that's related to your work. No need to get heavily involved. Look at the project, know what's going on, know the technology, know how it will affect your work. Write an opinion, recommendation, or just a report. Make it short and high-content. A pretty picture never hurts. Make sure to email it to PHB, as he probably won't remember to look at your intranet site. At least then his sec2 will have read it. Do this at least once mid-way through each quarter.
3. Write quarterly reports. Trump up any work you've done on popular projects, keep work on politically sensitive projects to a few lines. Again, email to PHB. This time he'll read it. They always read quarterly reports.
4. Request at least two weeks of training a year. Make these requests at least two months before you want to go, or within ten minutes of hearing your boss mention extra budget money. Include summaries of what you learned at these training sessions in your quarterly reports.
5. Request to go to at least two conferences per year. Again, write about what you learned at these conferences. Include in reports.
6. Write a yearly report and hand it over in November, along with next year's goals. Make sure your yearly report shows that you met or exceeded each of your goals.
7. Don't piss too many people off.
-----------------
So that's it. Do this and you'll be an information architect for as long as it amuses you. I'm serious.
Now if you need some ideas on training and seminars, and the general work part of being an information architect, just go here: Object Management Group - you should be able to take care of the rest here.
Good luck.
Ummm, yeah. None of the projects I've been involved in have ever had a 30 hour death march leading to implementation. Twice. In one week.
Seriously though, excellent point. Thank you. It's something I've done unconsciously for the most part, but will try to keep more conscious of in the future.
The truth about Scientology, Xenu, and you: Operation Clambake
As a recently-layed-off Senior Architect, I'm here to warn you about the practice of "fleshing" or "purging".
On October 12 I delivered the prototype of a system that involved JSPs, fat Java clients, J2ME wireless clients, JMS messaging, XML, etc., etc. Complete with designs to justify the use of Queues vs. Topics, stateless session beans to provide pooled access to the JMS, etc.
My boss said thanks. And then explained to me that since the comany was transitioning from R&D to maintenance and sales, the services of the people who'd designed the company's systems were no longer required, here's two week's severance, sod off.
The maintenance people are still in place. The architects and senior developers are looking for work.
I know that karma will come back to bite them in the ass, but the present is still a bitch.
668: Neighbour of the Beast
Submitting circumstances to public forum, and being able to assess viable conclusions is a *key* and vital skill required of anyone who desires to manage.
Never let yourself be governed by those who chose to run from hypocrisy or contradiction.
Garner this skill wisely, though. Don't capitulate to "collective think".
As an engineer, alway seek a solution that *solves* the problem, and never let the prejudices such as those stated by this troll to sway your judgment.
A good architect knows no bias other than a desire to get the job done, and done properly.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
Seriously my career adivice would be..
Get a girl/boy friend
Jump on a place and travel for a year using some of this money you've accumulated from being a hot coder. You should be visiting places like russia, iran and china - anywhere *interesting*
Get drunk with people you shouldn't - live to regret it.
Take casual job in a country where you don't speak the language - or one where you do but don't understand the culture.
etc. etc. etc.
The point? You've obviously been so keen on you 'career' you've forgotten what living is for. The USA economy is going into major recession and at the moment you are just another interchangable piece of cubical fodder. Go and grab some real life exerience while you still can, because in the long run it's what you learn and apply from that which is going to make your life and career worthwhile for the next 40 years - not being given some ridiculous company job title
I'm working on Enterprise Management using Tivoli, and architecting the system to cater for worldwide implementation in a global organization. Those of you familiar with this software know it is not trivial. If I didn't have the background of being a coder, tester, supporter and implementer, I'd have no clue how to design a complex system.
To answer your questions:
"...is architecture my most logical next step?"
- I'd say so. Do you want to be a code monkey for ever? Probably not. If you can code AND design, there is a much better future in it for you. Coders are a dime-a-dozen these days. Top-notch coders are rare. You can't just come out of the local community college and architect a complex system and do a decent job at it. You need experience.
When I first got into programming, I thought I'd do it for the rest of my life; it is that fun. Now I'd rather design a system from the ground up. It's almost like playing with Lego - and getting paid for it! Get your ideas together, design it on paper, and then build it using bits and bytes. I can design something, get programmers to help build it (getting my hands dirty at the same time), and see it work in a production environment. Then move on to the next project.
"What do I need to do to make sure my skills still remain sharp?"
- Study. Research. Read. Code. Code in various languages. Play with various OS's. Repeat. Be a mentor to others you work with. Share knowledge with each other.
When I'm done at my "day job", and when the wife and kid are asleep at night, I do research using the web. I learn new computer languages and new methodologies. I read /. I stay as sharp as possible, and using my skills and newfound knowledge, I can apply that to designing systems. Use the most appropriate tools available for the job. Maybe Perl. Maybe awk/sed. Maybe C/C++/VB. You get the idea. You might be limited by what your company allows.
The web is your friend. You can get ideas, software, and all sorts of stuff from it. You can learn at your own pace. In my opinion, you're much more "rounded" and "marketable" if you can do both development and architecture. Throw in support, implementation, various OS's, hardware/network setup and experience in many languages, and various methodologies, you will be employable anywhere you go.
It's not easy being an architect. You screw up, and it can make developers life difficult, and will require more support resources if it ever makes it into production. It could be a nightmare for your successor on the project. The reverse is also true. Wrong design decisions can be costly. Look at Civil Engineering. Design a bridge incorrectly, and it can be costly - it falls down and/or kills people. Software gone bad is just costly in different ways.
Learn as much as you can. In today's economy you can quite easily be laid off, no matter how good you are at what you do. That's life. If you can be a "jack-of-all-trades", the greater the chance of employment. Going from development to architecture design is a damn good move in my opinion. If you ever get laid off from your job, you could always fall back on your coding skills and maintain systems until the economy picks up.
Good luck.
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/
Dude, do you what a vagina is?
I believe it's a custom part of the female model of homo sapiens. It serves two purposes, one being an input port, the other being an output port. It functions primarily as part of the reproductive process of the species. It was designed for maximum flexibility, yielding to objects both small (like your penis), and large, such as a baby. Typically, the output method of the vagina forces it to operate much closer to maximum spec than does the input method. Like all body parts, it requires regular care and maintenence. Although it is capable of sequential serial input from multiple devices, the controlling system generally prefers utilizing fewer input devices over a longer term. The input/output ratio is heavily weighted towards the input process, as the output process uses many more system resources, both short and long term.
The truth about Scientology, Xenu, and you: Operation Clambake
About a year ago I went through this transition at a startup (FYI, that startup is no longer there) Here's a few things to look out for:
1. Many people inside a company may have different ideas of what an architect does. If you describe yourself as one, there can be all kinds of misperceptions to deal with.
2. In many companies, architects are considered a luxury item, so when times are tough they are rarely hired.
3. You will get age resistance, since most architects are older than you.
4. The definition of architect is very fuzzy. At some companies like Sun Microsystems, Architects have Phds and 10 years experience on average. They don't really lead a group, but primarily do specifications and handle
meetings (and occasional coding to stay fresh). At a startup, they are you and me. They could be asked to do almost anything from test planning to project management in addition to specifications and the like. Depending on where the managers/officers of the company come from they will have a different expectation.
BTW, don't take too much guff from people about being arrogant. I've led 40 somethings before too.. it's not that we are better.. just different. In my experience the 20 year guys don't want to deal with leading and are on their fourth or fifth primary language so I don't expect them to remember the details like I do on my 2nd.
Oh another side note, don't code on the project you are architecting if you can avoid it. Writing minor stuff or interfaces are ok, but not serious long term coding. I know a lot of people are telling you otherwise.. but it can often lead to odd, ugly conflicts of interest and time. What's easier to code is often not the right answer architecturally and with deadlines as they are.. well you see the problem.
DescSuit
If you don't mind my asking, how did you break into the field in the first place? I don't think I have the professional experience to be credible in that role yet, certainly in the current employment climate, but it's something I've considered as a longer term direction. The big barrier isn't so much my skillset or willingness to learn, which are developing OK, but rather the "foot in the door" principle. How did you get those first few jobs, so word of mouth could start to spread? Any background would be welcome. :-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Careful not to dig yourself a bigger hole with your ego (you are), it would be unwise to shoot yourself in the foot with that large a weapon. You're right we know nothing about you, but they say first impressions are very important and I agree with them. Again, you've probably hired people so you should know. Just get the job done, you don't have to prove every second of the day why you can get it done, just shutup and do it.
I am a young software architect, promoted a few years ago (when I was 26). The transition from lead developer was difficult, mostly because I resisted the fact that 'architect' is really quasi-management. It is a role that requires gobs of communication, documentation, and strong leadership skills.
The key, I find, is to somehow remember your passion for the role of desinging and preaching systems to a group on a regular basis. I look for things that remind me why I like coding, design, and bringing good sense to the people I serve. And remember, you serve the entire company; your role is to make decisions that will enable the business, and be within the abilities of the developmers and testers.
Ignore the fact that you are younger, it will only undermine your authority. Remember to excercise your authority when it is important, and to let the little things go. And, humility will buy you loads of respect.
Most of all, dream constantly about software design, etc. ... as innovation is the product of passion, and borderline insanity. And, never stop learning. Don't let a month go by without reading a dozen books and implementing at least a handful of things based on what you learn.
Will you stop coding? Only if you want to. You are now a leader, so if coding is essential, then you direct your copmany to allow for your position to code. I set asside 10-20% research time (coding/reading), and I prototype around many of the new technologies we add to our product regularly. And, you are Free to contribute to the GNU project in your spare time ;P
mx
If you are as proficient as you think that you are you should start your own company. Top of the class? In any other role you will be working for people stupider than yourself.
Wow, sounds like your a talented guy going places. A few thoughts from the peanut gallery: Many projects have architects but no architecture. Software Architects need to be part systems engineers. A smarter guy than me wrote that 70% of all software defects are requirements based. This means that figuring out what to do can be more important than being a rocking coder. Technical Architects take on the jobs that others may not be able to. Fight the fires that need fighting not what you find personally amusing. Architects never say, "I don't know how to do that, so its not my job to fix it". They say "Let's make a plan and figure this thing out with Bob, and Jane,...". I like to do Horizontal Prototyping early on. Creating a fabric for your less experienced team members to flush out can really help in Distributed Realtime/Communications stuff. (But I'm sure that's not new to anyone). Parallelism is the key to meeting deadlines. Keeping your team members moving can , at some times, be more important than sleep (provided your employer has good / and hopefully free coffee). Performance models are a hard sell, but they can save your butt. Might have to do on your free time. Dale Carnegie wrote that 20% of what you learn is technical, the other 80% is people skills. He was right.
I'm sure that's true, but that ignores the ass-covering type of meeting. These tend to be held on a regular basis regardless of whether there's any need for them, and the fact that half a dozen or a dozen people are present serves to provide strength in numbers: something must be going on, because a dozen people are meeting every week about it.
The sort of managers who run this type of meeting can be the opposite of the kind of person who can put on a show: they're the kind who likes to keep their head down and not be noticed when something's gone wrong. When something does go wrong, they can point to how they've diligently been holding allegedly productive meetings, and the problem must lie elsewhere, preferably in another department represented at said meetings.
I currently attend one of these every Thursday at 9:00am, hence my intimate familiarity with the species...
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.
Anusflange queries: "I recently was transitioned into a humping egotist by my employer. I had been over emphasising my involvement with development and architecture, for some time. It appears my new duties allow me more channels in which to polish my ego. The company has agreed that I can use company headed fax paper with 'Software architect evangalist god' when I only have skills in notepad++. At not even 28 years old, I'm already a self-opinionated wanker and have people with twenty years more experience hoping that I have an accident on the way to work. Over that past year with my employer, I've expended much effort on absolving myself of any responsibity 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, whats my best way to masturbate in public? What do I need to do to make sure all the women in the office love me, and all the developers worship my ability with the DOS prompt, 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 are appreciated, but more than anything, I'd love anyone who isn't as fortunate as me, both intellectually, and finacially, to know how well off I am."
One trend that (for better or worse) has been building for the past few years is the building maturity of software as an engineering dicipline. We're not there yet, but in about 15 years some of us will be counted on to develop systems that will be verifiably bulletproof and someone will be sued if it fails. (We may look back at the 90's as the good old days when even high-school kids could make good money cranking out code.)
150 years ago bridges used to collapse regularly; even 100 years ago bridge collapses were not unusual. But today, we're building bridges that will be around forever. What happened? Just before the American Civil War, Civil Engineers got together and decided to become more professional. This also led to standardization of building materials and design processes. Yes, you don't see people building bridges and dams totally off-the-cuff, and it takes a few months to do it right. Today, most bridges have a signature of a certified Civil Engineer on the blueprints and you can guess where the lawyers will be looking if there is a problem.
In the next few years all the SW-CMM process stuff will become critical ( http://www.sei.cmu.edu/ ). There are a few highly organized projects deployed and becuase we're taking measurements we can show that going through all the steps does decrease costs in all phases of a project. With the dot-bomb contraction there's a little less pressure and a little more time to do it right the first time.
The group that will push this through are those who are today identified as (usually) Architects. If you have a customer who can't figure out why there's an Architect on the project who's billing at a higher rate than a coder and yet doesn't produce any executables (my current problem) you can go back and show how, by applying a dicipline, the resulting system will be more stable and usable (my current solution). And even a PHB will see that--developing the communication skills to explain (as best as possible) the latest neat-o blivet to the founder's son is the hardest part of the job.
Of course, I'm still coding. But as a previous poster brought up, it's only to help out in a crunch or to get something started and ultimately my code is maintained (or rewritten) by someone else within a month of my writing it. But actually coding a, say, JSP is the only way to grok what you can do with it.
And giveback? Mentoring that new kid or getting that old COBOL programmer to get with the program is easy. Getting your employer to see the value of process is valuable (start with a new, small project and collect some quantifiable measurements). We are going to have to build a solid environment that we can develop solid systems on, and I don't think it will come from any MonopolieS.
Just to play devil's advocate, I'm going to propose this: software development is so inherently unpredictable that an architect's work is largely useless! In other words, coming up with an overall software design is the easy part. Yeah, you need to do it, but it's almost a tongue-in-cheek endeavor because you know it's all going to change anyway. How many times do you get into situations where the final result bears very little resemblance to what's in the original architectural documentation? It's happened to me in every single project I've worked on. The real brains are at the development level because that's where you have to think on your feet, analyze real-world behavior of that function or API that you thought you could use but turned out to be for sh*t, come up with workarounds when you find out that X component isn't compatible with Y component, etc., etc. The more experience I get with this industry the more I get the feeling that the "higher" you go on the totem pole the "dumber" you can be and still fake the job! Right on up to managers who know zilch. And I'm not talking about IQ, either -- from my perspective, it looks like when someone gets promoted to a "higher level" position it's almost like they are retiring, not assuming a more difficult job -- kind of like "I paid my dues, now I can start to take it easy a bit and relax". You know -- like they are sick of memorizing API's and want to sort of rest on their laurels and deal with software on a "higher level". I have felt this way for a while, and I keep feeling like someday there's going to be this great revolution in the software community where it's like "the Emperor's New Clothes," and someone somewhere is going to say "hey, wait a minute, that manager that's earning way more than that developer doesn't know jack sh*t!" Even if he/she did at one point and went soft/forgot it all/got outmoded. It just seems to me that software is complicated, it's not simple and it can't be reduced to simple principles, ever. So the person who really has to get their head around all that complexity and all those specifics and know and remember it all is really the person who should be "honored" the most.
Whatever -- like I said, I'm playing devil's advocate. But until I run across a real life situation where it's obvious that the "upper level" folks are really assuming more responsibility than the developers -- not accountability, mind you, but responsibility -- then I'll change my mind. It's entirely possible that for all I know I've just been unlucky so far in terms of the management teams I've been exposed to. Fact is, I'm still waiting for it all to make sense -- and that means making sense to someone who accepts 0.0% B.S. and 0.0% compremise of principles.
I could go to Europe
Travel with my friends
I could blow a thousand deutschmarks
To get drunk in a pub with some Australians
Buy a giant backpack
Sew a flag on the back
Think never is enough
Yeah never is enough
You never have to do that stuff
Actully, I agree with you quite a bit... but there are lots of great life experiences to be had doing just about anything. You don't have to get drunk in a place where you don't understand anyone to have a Life Experience - you can do simple stuff like volunteering for things right in your own city.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
To address this post and the addendum you added on, I agree strongly with both points - development in the end is the most important task, though teaching is more important than even that!
I think the role of Architect as being like a gardener - you plant an idea/API/framework with a person or group. Then from time to time you come back to watch it grow, and see how it develops under the care of the group/person you have working on it - you can make suggestions for how it should grow and change over time.
But developing various systems and API's is only tangental to the real work. An architects primary goal should be to help others develop into architects as fast as possible. That's why I think a hands off approach is important, to let the other people learn as quickly as possible from the work at hand.
Thus an architect should be spending time shoring up weak areas, and planning ahead for how various projects under development can eventually mesh well.
In summary, architects can be very useful when they realize they are there to SUPPORT the real work, and to TEACH others how to provide said support. Managers would do equally well to remember the only goal they should have is support of real work and workers.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
And if it doesn't play well here, it isn't going to go down any better at work...
Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra
Joel Spolsky, another engineer-turned-architect writes thoughtful, entertaining, straightforward essays on these topics and other elements of software management based on his experiences at MSFT (regardless of your opinion of their business practices, they are certainly successful at orchestrating large, complex software projects) and, more recently, at his own company.
This stuff is such good reading that I've converted most of it into Plucker format for browsing on my PalmOS device. You never know when you'll need it for reference or inspiration.
Some personal favorites: The Joel Test of effective s/w development processes, painless software schedules, writing effective (read: convincing) functional specifications, and plenty of other gems.
307 comments yet, but noone mentioned UML...
Rewrote the removed functionality in approximately 4,000 lines of C and imbedded SQL.
The problem was that management allowed the code to reach such a state. But thats what happens when management only understands SLOCs
It's also what happens when good programmers are encouraged to only fix hot bugs and not allowed to re-factor bad but "working" code when they find it.
where there's fish, there's cats
Is it me, or has the whole line of job titles kind of jumped up a notch? I think this happened sometime around when the "Architect" title came into constant use. Maybe it's a good thing, as the real Architect's are really calling themselves CTO's and getting that extra week of vacation.
Krispy Cream is people
Your not management, and you don't directly make management decisions. But every manager should get your advice at review time for any employee you have an opinion on. (and if you don't have one on someone that says something too, but what is never sure)
Make sure you are in charge. Marketing tells you what will sell, but you have to figgure out what can be done. Often you will know more than them, but still take their advice seriously if you can.
Be in charge. don't let micromanagers dictate stupid design decisions. Don't let programers make stupid mistakes. When someone is doing something wrong you need to step in and say "NO! that can't work". Don't be afraid to do it.
Know what everyone is doing. that goes with the above. Review everyone's code, at least part of it if the project is too big. You don't have time to test and debug it, but you should know something about it. (formal code reviews are important, but you don't need to be involed with them nessicarly, just know the code)
Logical error. Criticizing others implies that the criticizer does not suffer from the specified faults. It's self-aggrandizement by implication.
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.
In a commercial environment, if you want to avoid that, you pretty much have to move up the ladder, which is ultimately going to mean team lead, project lead, architect, mentor, consultant, or something along those lines. If, however, you program for fun, none of this really applies.
I feel that at 28 my skills are better than they've ever been
Assuming you don't let yourself stagnate, you'll feel the same way at 38, and probably even at 48, as long as you don't suffer from any degenerative brain diseases. But observing some of my colleagues and even myself, stagnation is all too easy as time goes by. It's tempting to think that you know everything you need to know.
You have to challenge yourself. Don't just read the magazines and books you find in bookstores (you know, Dr. Dobbs and Teach Yourself Java in 21 Days), get hold of and work through some of the books that are famous in academic circles (e.g. SICP, to name just one obvious one), subscribe to some ACM journals, learn new languages, take some advanced courses. Take on projects that challenge you, that you don't understand how to do. Learn what you need to learn to do them. (Don't necessarily do this for projects that your career depends on, though!)
Not only will this be personally satisfying, but it'll make you more marketable, too.
Yeah, that's a great idea.
But it doesn't answer the fucking question, does it?
-Peter
PS: Get a fucking login, twit.
-P