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
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
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
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!
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.
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
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.
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?
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.
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. --
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/
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.