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. --
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
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).
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.
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.
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.