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