faq
code
awards
privacy
journals
older stuff
rob's page
preferences
submit story
advertising
supporters
past polls
topics
about
bugs
jobs
hof
|  Coder or Architect? |
 Posted by
Cliff
on 01:10 PM October 21st, 2001
from the arriving-at-that-fork-in-the-road dept.
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."
< Quarter-sized CD's?
| Security Issues with Windows 2000 Datacenter? >
| |
|
|
Coder or Architect?
|
Preferences
| Top
| 405 comments
|
Search Discussion
|
|
|
|
The Fine Print:
The following comments are owned by whoever posted them.
We are not responsible for them in any way.
| |
(1)
|
2
|
You're doing the right thing (Score:5, Insightful)
by Troed on 01:14 PM October 21st, 2001 (#2456759)
(User #102527 Info | http://slashdot.org/)
|
I'm in the same position, and my advice is to take architectual, technical lead and "fire-fighting" roles. I.e, no slave-coding.
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 ...
The lies of the USA [indymedia.org]
|
|
[ Reply to This
| Parent
]
|
|
| |
Whatever: Just get the job done. (Score:5, Insightful)
by torpor (seclorum2mac.com <2=@>) on 01:17 PM October 21st, 2001 (#2456770)
(User #458 Info | http://www.ampfea.org/)
|
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.
~jv
-- threads rolling, keep the threads rollingg ...
~
|
|
[ Reply to This
| Parent
]
|
|
| |
Simple advice: Don't get swamped in meetings (Score:5, Informative)
by chancycat (evanhatesspam.bigatsign.yahoo.com) on 01:20 PM October 21st, 2001 (#2456784)
(User #104884 Info)
|
|
From a huge company made up of engineers and "architects" if you will - be ware of this:
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
|
|
[ Reply to This
| Parent
]
|
|
| |
Architect also implements (Score:5, Interesting)
by esap (esa.pulkkinen@kotiposti.net) on 01:27 PM October 21st, 2001 (#2456804)
(User #2010 Info | http://sivut.koti.soon.fi/epulkkin/)
|
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 [bell-labs.com] (http://www.bell-labs.com/user/cope/Patterns/Proce ss/section16.html) software process pattern for a detailed overview.
--
Esa Pulkkinen
|
|
[ Reply to This
| Parent
]
|
|
| - 1 reply
beneath your current threshold.
|
We regret to inform you... (Score:5, Insightful)
by john@iastate.edu on 01:33 PM October 21st, 2001 (#2456833)
(User #113202 Info | http://www.ait.iastate.edu/bio/john.html)
|
|
Since I've already resolved that management is not a track I want to get into, is architecture my most logical next step?
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
|
|
[ Reply to This
| Parent
]
|
|
|
Advice (Score:5, Interesting)
by piyamaradus on 01:38 PM October 21st, 2001 (#2456847)
(User #447473 Info)
|
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!
|
|
[ Reply to This
| Parent
]
|
|
| |
hmm, a few random thoughts.. (Score:5, Interesting)
by ckuhtz on 01:39 PM October 21st, 2001 (#2456856)
(User #87644 Info | http://www.kuhtz.com/)
|
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.
|
|
[ Reply to This
| Parent
]
|
|
| |
The fallacy of this story (Score:5, Insightful)
by ergo98 on 01:49 PM October 21st, 2001 (#2456886)
(User #9391 Info | http://www.yafla.com/)
|
|
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).
|
|
[ Reply to This
| Parent
]
|
|
| |
Free-lance consulting (Score:5, Informative)
by Ldir on 01:53 PM October 21st, 2001 (#2456902)
(User #411548 Info)
|
|
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?
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.
|
|
[ Reply to This
| Parent
]
|
|
| |
Position vs Role (Score:5, Interesting)
by stumbler (ameyer at mail dot com) on 01:55 PM October 21st, 2001 (#2456909)
(User #219354 Info)
|
My 2 cents ...
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 ... thats a full time job.
You'll really hurt yourself if you try to be a General and an Elite Commando at the same time .... focus on what's inportant for the role you are playing, and let your talented software engineers play their role.
|
|
[ Reply to This
| Parent
]
|
|
| - 1 reply
beneath your current threshold.
|
Can I come work for you? (Score:5, Funny)
by flockofseagulls on 02:20 PM October 21st, 2001 (#2456986)
(User #48580 Info | http://slashdot.org/)
|
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?
|
|
[ Reply to This
| Parent
]
|
|
| |
Architect == My Shit Don't Stink (Score:5, Insightful)
by Saint Stephen on 02:26 PM October 21st, 2001 (#2457015)
(User #19450 Info | http://slashdot.org/)
|
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.
|
|
[ Reply to This
| Parent
]
|
|
| - 1 reply
beneath your current threshold.
|
Architects need to be wide as well as deep (Score:5, Informative)
by James Youngman on 02:29 PM October 21st, 2001 (#2457026)
(User #3732 Info | http://www.free-lunch.demon.co.uk/)
|
|
The nature of the architect role varies a bit according to whether you are an architect for a product (or a product suite) in a company working in one industry segment, or an architect working for an IT consultancy. In the former case there is a great emphasis on development strategy and an understanding of the market but in the latter case while these factors are important, you will also need some analysis skills and perhaps some sales skills.
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. Read the rest of this comment...
|
|
[ Reply to This
| Parent
]
|
|
| - 1 reply
beneath your current threshold.
|
How to be a successful Information Architect (Score:5, Insightful)
by jonbrewer on 03:18 PM October 21st, 2001 (#2457148)
(User #11894 Info | http://www.rock-chalk.com/)
|
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 [omg.org] - you should be able to take care of the rest here.
Good luck.
|
|
[ Reply to This
| Parent
]
|
|
| |
Support, Develop, Architect (Score:5, Insightful)
by Toolsmith on 04:17 PM October 21st, 2001 (#2457307)
(User #209721 Info | http://www.harbrink.com)
|
|
I've been in IT professionally for over eleven years.
In that time I've done system testing, support, implementation, and development. For the past 3 years or so I've been on the 'architectural' path. Using my past experiences, I find I can better design complex systems keeping the aspects of security and scalability in mind.
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 monkkey 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 varioous 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.
|
|
[ Reply to This
| Parent
]
|
|
|
The question is not whether you re done coding (Score:5, Interesting)
by Zeinfeld on 04:31 PM October 21st, 2001 (#2457346)
(User #263942 Info | http://slashdot.org/)
|
|
I've been in the business over twenty years. I'm 35, I was earning enough to pay taxes when I was 13. Back then we reconed that nobody could code worth a damn past 30.
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.
Who is the NSA target of the day [127.0.0.1][target.nsa.gov] in the war against terrorism?
|
|
[ Reply to This
| Parent
]
|
|
| |
Possibly unpopular opinion, but here goes (Score:5, Insightful)
by incrediblytired on 11:02 PM October 21st, 2001 (#2458385)
(User #528945 Info)
|
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.
|
|
[ Reply to This
| Parent
]
|
|
| |
Odd contradiction (Score:4, Insightful)
by Ars-Fartsica on 01:14 PM October 21st, 2001 (#2456762)
(User #166957 Info | Last Journal: 12:35 PM August 18th, 2001)
|
|
You go to great lengths to describe to us your engineering prowess, but then you solicit the opinion of college students and other random posters for your career development. 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.
|
|
[ Reply to This
| Parent
]
|
|
|
Rubbish. Ignore this foolish troll. (Score:5, Insightful)
by torpor (seclorum2mac.com <2=@>) on 03:50 PM October 21st, 2001 (#2457244)
(User #458 Info | http://www.ampfea.org/)
|
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.
~jv
-- threads rolling, keep the threads rollingg ...
~
|
|
[ Reply to This
| Parent
]
|
|
| - 1 reply
beneath your current threshold.
- Re:Odd contradiction by Reality Master 101 (Score:3) 01:33 PM October 21st, 2001
- Re:Odd contradiction by camusflage (Score:2) 03:00 PM October 21st, 2001
- 1 reply
beneath your current threshold.
- Re:Odd contradiction by nullrun (Score:2) 04:24 PM October 21st, 2001
- 10 replies
beneath your current threshold.
|
Keep coding (Score:4, Insightful)
by Pedrito (pdavis68@hotmail.com) on 01:26 PM October 21st, 2001 (#2456801)
(User #94783 Info)
|
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.
-- "Beware of bugs in the above code; I have only proved it correct, but not tried it."- Donald Knuth
|
|
[ Reply to This
| Parent
]
|
|
|
Keep coding... (Score:4, Insightful)
by jpbelang on 01:28 PM October 21st, 2001 (#2456809)
(User #79439 Info | Last Journal: 12:47 PM September 4th, 2001)
|
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
|
|
[ Reply to This
| Parent
]
|
|
| |
Been there, done that (Score:4, Insightful)
by SerpentMage (cgross.devspace@com) on 01:29 PM October 21st, 2001 (#2456818)
(User #13390 Info)
|
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.
|
|
[ Reply to This
| Parent
]
|
|
| |
Be flexible but go with your strengths (Score:4, Interesting)
by Anonymous Coward on 01:57 PM October 21st, 2001 (#2456918)
|
Actually 28 is just about the age to get into senior slots (how old is that in dog years :-)?).
You should check out Norm Matloff's Debunking the Myth of a Software Labor Shortage [ucdavis.edu]. 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.
|
|
[ Reply to This
| Parent
]
|
|
| |
How to keep your hand in coding? Wait for crises. (Score:4, Interesting)
by The G (ggould+sdp@alum.mit.edu) on 02:14 PM October 21st, 2001 (#2456964)
(User #7787 Info)
|
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
|
|
[ Reply to This
| Parent
]
|
|
| |
Architecture vs engineering (Score:4, Informative)
by peril (toilethead@bathroom.com) on 02:19 PM October 21st, 2001 (#2456983)
(User #11405 Info)
|
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
|
|
[ Reply to This
| Parent
]
|
|
|
Architect is a temporary role (Score:4, Insightful)
by hargettp (hargettp _at_ mindspring _dot_ com) on 02:19 PM October 21st, 2001 (#2456984)
(User #74445 Info | http://slashdot.org/)
|
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; thatRead the rest of this comment...
|
|
[ Reply to This
| Parent
]
|
|
|
Here's a hint (Score:3, Funny)
by Anonymous Coward on 01:27 PM October 21st, 2001 (#2456806)
|
|
Don't make statements like: 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.
|
|
[ Reply to This
| Parent
]
|
|
|
Yes, but he's the essence of the /. user (Score:4, Flamebait)
by Ars-Fartsica on 01:39 PM October 21st, 2001 (#2456855)
(User #166957 Info | Last Journal: 12:35 PM August 18th, 2001)
|
|
The reason your post will eventually get modded down is that the submitter is manifesting the secret wet-dreams of everyone on /. - they all want to think of themselves as special, as prodigies. 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.
|
|
[ Reply to This
| Parent
]
|
|
| - Re:Here's a hint by testpoint (Score:2) 04:24 PM October 21st, 2001
- 8 replies
beneath your current threshold.
|
I have a suggestion... (Score:3, Funny)
by Mike Schiraldi (mgs21@columbia.edu) on 01:28 PM October 21st, 2001 (#2456813)
(User #18296 Info | http://sf.net/projects/hilite)
|
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.
--
This symbol: ♣ ...is to get your attention [sf.net]
|
|
[ Reply to This
| Parent
]
|
|
| |
That's another issue Extreme Programming solves! (Score:3, Informative)
by Anonymous Coward on 01:31 PM October 21st, 2001 (#2456826)
|
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.
|
|
[ Reply to This
| Parent
]
|
|
| |
Start your own company. (Score:3, Insightful)
by ClarkEvans on 06:35 PM October 21st, 2001 (#2457623)
(User #102211 Info | http://clarkevans.com)
|
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.
|
|
[ Reply to This
| Parent
]
|
|
| - 1 reply
beneath your current threshold.
|
Making the Transition (Score:3, Interesting)
by Salamander (jeff1@taCOFFEEmbreet.com minus caffeine) on 09:54 AM October 22nd, 2001 (#2459819)
(User #33735 Info | http://www.platypus.ro/ | Last Journal: 06:35 PM August 19th, 2001)
|
|
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.
|
|
[ Reply to This
| Parent
]
|
|
| |
(1)
|
2
|
|
 |
|
|
|
QOTD:
"I'm not really for apathy, but I'm not against it either..."
|
|
All trademarks and copyrights on this
page are owned by their respective owners. Comments
are owned by the Poster.
The Rest © 1997-2001 OSDN.
|
[
home |
awards |
supporters |
rob's homepage |
contribute story |
older articles |
OSDN |
advertising |
past polls |
about |
faq ]
|
Coder or Architect?
