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've been down this road before. At my last job, I was promoted to Special Projects Coordinator, and also had guys twice my age coming to me for answers. It was quite cool for about 6 months, but got old quite quickly. The only way that I could get back into a coding role was to leave the company and move on. No matter how hard I tried, everytime I would move into coding something new, another person would be hired for me to manage, and it just got to be impossible to get any hands on programming done where I wasn't just fixing 10 lines of someone else's mistake all the time.
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 forgot to add "like Walmart". You fail.
Reads like your an excellent and servile bootlick and very capable social climber. Good luck in your career and hire many contractors (to bail your ass out).
I moved from developer to architect/developer and then into manager/architect/devleoper. There's no doubt that between the three jobs, I find it very hard to do any single one completely. I've been fortunate to have a really great team who I now share the management and architect duties with. I still have the final say on architecture, as I designed the flagship product for our company, but I'm very open to ideas and fortunately have very talented people working with me.
The key to keeping your skills sharp, though is to keep writing software. Not just as a hobby, but as part of your job. Find the time to do it, somehow. If you lose that skill, you're in a position where you could lose your ability to effectively architect and manage (assuming you ever do that as well). My advantage is my roots as a developer and the fact that I maintain it. My best managers in the past were technically proficient and understood problems I was facing, and I could explain it to them in my language. If you lose that, you lose that effectiveness.
This is just my opinion, but it's based on my past exerpience as a deveoper and my current experience as manager/architect/developer.
It's definitely a lot more work than it used to be, but it's also a lot more rewarding. If it wasn't, I'd go back to just being a developer.
You cannot be an architect unless you also implement, since it's impossible to design the architecture unless you know what happens inside the software. And you cannot get this knowledge without participating in the implementation. Therefore, there is no problem. The only thing is, there are higher hopes for you (in addition to the ordinary requirements for coders, you are also expected to actually design the system!) It's just more responsibility. Nothing else changes!. See the Architect also implements (http://www.bell-labs.com/user/cope/Patterns/Proce ss/section16.html) software process pattern for a detailed overview.
-- Esa Pulkkinen
At not even 28 years old, I'm already a lead developer and have people with twenty years more experience looking to me for coding hints and tips.
It makes you sound like a real asshole.
The only way to keep your skills sharp is to keep coding. "Pure" architects, the ones who only write edicts from an ivory tower tend not to keep their skills for one simple reason: problems do not normally reside in architecture but implementation (you really pick up on problems in implementation). So you could always work on home projects.
:) )
The second option is to push for a method like XP (Extreme programming) in which everybody codes (in pairs). This allows for your skill (the coding skill that got you your promotion) to be transmitted to other members in the team and to the project you'll be working on. Who knows, you may pair up with a kid out of college who'll teach you a thing or two about coding or ressource management.
Lastly, a rant: why do organizations try to push techies out of the jobs that they do well ? I've seen a gazillion good coders move into management jobs and just Peter Principle out. I've seen good coders move into architecting jobs and all of a sudden lose perspective on the goal of system developpement: deliver a system.
Why is going into architecture or management a promotion ? Shouldn't it be a skill ?
JP Belanger (just a programmer
jpbelang at eloas dot qc dot ca
JP http://www.wearerite.com
Stop getting your hair cut for a while. Then, when it is long enough, get it shaved down the middle and apply mousse to fashion the remaining hair into two pointy shapes.
--
Mod up a post Rob doesn't like and you'll never mod again
I'm 28 and I think that I'm really awesome. To show this I will list a whole bunch of crap that I've been through in the 6 years I've been out of college. Then I will tell you where I am currently heading and I will wait for the entire slashdot crowd to read in envy and then post about how awesome and on the right track I am. Oh, by the way, I rule.
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"
Code Free Software in your spare time!
And don't let yourself get sucked into project design/managemnet, which would defeat the purpose.
-Peter
I suppose I'm a smart person and good programmer. I could give advice to most of my professors about programming and I love helping people out (I think my ideal job would be tutoring). Only I just don't think anybody would hire me. I will only have an associates degree in about 5 months, which I thought would be good when I started out but now I'm not sure. Also, I've just done so badly at every other field I've tried... but that's because programmig is the only thing I know how to do.
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.
Heaven forbid the geeks question the "infalibility" of their own circle-jerk (err, "forum") for mutual support.
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
The most important point made here: Stand your ground and don't let yourself become slaved to the project management.
You will find yourself in a unique situation, with one foot in engineering, and the other in management. As a result, you will become management's favorite go-to guy. Similarly, the engineers that you work with will also try to use you to influence the decisions of the managers. Be fair and responsive, but don't feel you need to cater to everyone's whims.
You will have to a little delegation, but don't it let monopolize your real job. Commit yourself to planning and writing code, and just being productive. You will not lose touch with your skills in this way.
Black holes are where the Matrix raised SIGFPE
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!
Any 'architect' that does not do extensive development only manages to create problems for others to solve. Any 'developer' that does not architect his solutions is no more than a 'coder'. Paper design is an exercise in futility as the most important issues are where the tires meet the road. They may indeed be trying to turn you into one of those brainless managers that know less than anyone else working on it, that technical/management division so many companies are fond of.
They cling to the notions that experience should be subborned to genius, with the provision that they be recognized as such.
There's a deep inherent smugness around here, but as Chuck wrote in Fight Club - You aren't special. You aren't a precious little snowflake.
Be prepared to spend a lot more time researching
and reading and talking about strategic decisions.
Being an architect means that while you need to
make tactical decisions on an on-going
basis, you do need to spend a considerable amount
of time to look at the long term aspects of
projects and worry about how things will come
together, where you want to end up etc.
You can also expect to be less and less hands-on.
And that's where perhaps the biggest challenge
lies: You need to keep up and be sharp on not
just today's stuff, but just as much the many
tomorrows and potentials and try to make decision
today that set the right direction.
It can be a quite daunting task depending on how
quickly your area is evolving. How do you stay
up on the details, while not getting lost in
them, and know enough to make (or prepare) key
strategic decisions without having the same
hands-on exposure as you have when in the
trenches.
So, expect to spend a third if not two thirds of
your time on strategic work, reading, talking to
people, brainstorming, participating in industry
forums, whatever is suitable for your specific
niche (and even that's not a proper term for
architects as you really need to look and think
outside the box).
Simply leading others doesn't make you an
architect. Architects are visionaries for the
company, and in addition to technical and
political prowess, you should also posses a good
bit of entrepreneurial spirit. Those are key
ingredients to making sound architectural
decisions.
Because you'll have less hands-on, you'll also
need to become quite skilled in dealing with the
people who are in the trenches. You need to
develop a network of people, develop people skills
to work with others to glean experience and
knowledge without neccessarily directly working
with products. Yet, unlike your general (bit
perhaps some technical) manager, you need to be
able to have the skills, people and technical, to
interact with others and sort out fact from
fiction.
Architects need to have a sound understanding of
the business itself. Many decisions you make as
an architect are in liason roles: You serve as
the joint between the technical guys in the
trenches and management on the other side. You
need to communicate well with either. The
techies will want you to make sound decisions to
not make their life any more hell than it
already is, and the manglers will want sound
business decisions (which includes politics,
finance, technical etc etc).
Don't be afraid, just do it :^).. we all learn
every day as we go.
True architects do not really have managerial
responsibilities if they are supposed to have
time to do all the other things they have to do
to explore all the 10 choices of which you're
going to chose one, and of which 9 are a waste
of time at the end.
Getting management to understand that a lot of
an architects tasks (time wise) don't neccessarily
yield results is crucial.
And ditto for the techies who'll wonder why you're
wandering off chasing a tangent you find
important but that is beyond their tactical
horizon.
Hope this helps.. Good luck.
Poof.
..would be to work on your inflated ego problem. Or perhaps you -should- move into management, where that problem magically becomes a qualification.
got the ISBN???
learn how to draw buildings
oh how we laughed!
To keep your skills sharp, watch what other people are doing and create your own prototypes.
;^)
I've found that most budding architects (code, hardware, and buildings/bridges) eventually forget that people have to implement their personal nightmares and end up envisioning massively hierarchical systems which are impossible to...
1. manage the development
2. debug the faults
3. document all the features
Rule of thumb is if you can't imagine doing it, it probably won't be done the way you want. It may take you 50 years, but that's what all those designers are for. Also most failed architectures are done w/o consulting the designers that do the work. If you don't know how it's supposed to work either ask a designer, or figure it out. As an architect, you are responsible for both form and function. Lots of folks forget the latter in their quest for the former...
Prototypes (and different modelling technologies) are really useful for seeing if ideas really work or not. Sometimes it's hard to convince people that powerpoint and microsoft project are not modeling tools, but that's a common pitfall. Prototypes don't have to work, but at least they force you to think about the major issues. An Excel spreadsheet that estimates performance, for instance, is a fine modeling tool.
Documentation is the other issues. Budding architects micro-spec their projects. They tend to forget big stuff like performance, testing, proper functioning in the face of problems, future proofing, etc. Remember, most designers can figure out the details.
Oh, yeah... perfect is the enemy of done. Although I can't take credit for that gem, it's a truism that's easy to forget...
If I have some time later, I'll talk about software architecture instead of how to architect bridges...
I originally started as a programmer in college (ok, first was the track for electrical engineer, but alas, calc II killed my plans less than kindly) and touched on some of the aspects of design, development and some of the "herding cats" aspect of project management.
I'll be the first to admit that I did not have the stamina to code for a living, which lessened my interest in doing so. Like anything of interest, it is a slow learning process.
For me it was a slow degradation of the fun aspect of programming. The thrill is still there, but, the hard work of programming just kind of wore me thin (figuratively speaking, of course...literally, wellll, lets not talk about it).
As a "Lead Developer" for your company, you have both my admiration and my condolences.
My condolences, because it is always hard breaking away (or being forced away) from your "first love", so to speak.
My admiration, for you are moving up and are getting the realization that it is a needed step.
Here is the thing that may or may not hit you sooner or later, as it has happened to me on a couple of occasions: the people "under" you are better than you at coding, more often than not.
It is a harsh reality to face, but here is the kicker: Yes, your underlings are better at coding, but not at design and architecture! Hence, your position is more important than you think. To put out to you the words of wisdom/cliche, "those that know how, will always work for those that know why".
Think about it, really. Your role is more of a teacher, guru, advisor or sensi (SP?).
You've been there, done that and you've got the experience of the big picture that those you work with need.
I know first hand from working with coders, techs, IT, MIS people that are so sharp they could have my job in a heart beat, but, invariably I find the one thing they are missing is the why. As a matter of fact, one particullarly sharp individual thanked me saying "in school they tell you how without explaining the when, where, and why it is done in the process".
You have to see that you are in a unique position of taking the fear and uncertainty and doubt out of the the process of development and coding.
At the risk of sounding very silly, it is quite a "Zen" feeling, because you have to let go and move up in order to be the best person for the job.
I think physiclly, you are there, the reality has yet to catch up to you.
FWIW, naturally.
Have you read the moderator guidelines? Well, have you, PUNK? (and I want a Karma: Gnarly option)
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).
Hi, I really want to be a glue sniffer but currently I am stuck in a place that only allows me to be a paste eater. What should I do? And perhaps one day I really want to be a system administrator- just because I think it would be fun to incriminate my users by putting porn in their $HOME. Any suggestions?
If you happen to know anything about computational geometry please email me at bondowine@yahoo.com- I need some help.
Why is this "story" even on the front page? Go back to being a code monkey, or keep doing what you're doing. Nobody cares.
(quote) 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. (end quote)
Once I was trying to explain why it is tough to get computers to guess at typos and try to match mistyped car license plate numbers as well as guessing humans, and the manager suddenly stepped out of the room and whistled to my supervisor ("systems architect", et al) to come over and translate my alleged nerd-speak. It was like, "Just a second, Yo! Translator, over here!"
I eventually did make a Guess-A-Tron, but they did not want the results anymore by then. But, it was a fun project.
Table-ized A.I.
Ask a lead architect how much what exactly needs to be done to hold 12 tons of machinery on a floor and they design that and hold pretty much perpetual legal liability if it doesn't.
Designers know that some light colors in the corner will make the room feel bigger.
You, honey, are a designer.
So if that means that you are in charge of the MANAGEMENT of the product, don't presume that you are their because you are supposed to be a better coder than they are.
I've worked with several application designers who are terrible at the details of coding. However, they understand the higher level needs of what the code is supposed to do.
Get over the fact that you think this position means that your skills are a superset of theirs. Herd the cats, learn how to spot trouble areas and learn some project management.
You're not peaking, you're just learning a valuable skill that complements coding.
Since I've already resolved that management is not a track I want to get into, is architecture my most logical next step?
No, getting a girlfriend is your next logical step.
After listening to this guy polish his ego in front of us for two paragraphs, I can say with certaintly that this is one individual that I would in fact want tied up in meetings. Endlessly.
For what it's worth, I faced the same issue as my career migrated into management. The more I advanced, the less hands-on I could be. That didn't work for me; not only do I enjoy the hands-on work, I've always felt that management is more effective when it has some idea of what it is managing.
My solution is to moonlight as a free-lance consultant. I focus mostly on small, privately-owned companies that need solid expertise, but don't need 40 hours per week and can't afford $200 per hour. I establish a base rate of $150 per hour, just to place myself in the market, then discount it sharply to what the companies can afford. They understand up front that my work is almost exclusively after-hours. In return, they get a big discount.
I mostly rely on word-of-mouth for business. These business owners do talk to each other, and they'll enthusiastically recommend someone who gives good service. I also let local vendors know what I do, not your CompUSAs necessarily, but local branches of business systems (e.g., Sun, IBM). They often have customers who need a hand, but can't afford their big project rate structure. I'm not a threat, since I will not and cannot commit to anything that takes major manpower.
I've been doing this for 15 years or so. It keeps me hands-on. It's also a great source of extra income, pays for the tech "toys" I use in my business. In the process, I had to learn a lot more about running a business - tax and financial issues in particular - which is valuable in my real job.
My only caveat, be realistic about how much time you can spend over the long term. It's fun at first, but the novelty wears off. It gets to be work, especially when the weather's nice or there's a new example of your favorite addiction (games, sports, books, whatever). Your clients depend on you. If you leave them hanging, you can hurt their business.
That's a great combination of fields, coder and architect! You can write CAD software for designing buildings, or figure out exactly how to run your UTP cables, or position the windows so you don't have reflections off your monitors...
Huh?
A *SOFTWARE* architect?
Oh. Never mind.
My 2 cents ...
... thats a full time job.
.... focus on what's inportant for the role you are playing, and let your talented software engineers play their role.
An architect can sometimes be though of as a technical organizer.
It's a role more than a position. An architect steps in when you have a group of developers and you need to get from point A to point B with as little risk as possible (technical and/or otherwise.) You should take into account business goals, technical skillset, marketing requests, and supportability.
One you and your team have layed out the architecure, and aligned it with the various business goals, there is nothing wrong with you taking a *minor* programming task, assuming you have time.
But also realize that architects play by differnt rules than coders. Your skillset in dealing with groups of technical AND non-technical people will be more important that your skillset in a particual language. Your ability to leverage the your companies talented programming staff to produce someting everyone is proud of (and also happens to be on-time and under budget) will be the what you are measured by. Making sure you have an architecure that can adapt you the changing needs of your business
You'll really hurt yourself if you try to be a General and an Elite Commando at the same time
You should check out Norm Matloff's Debunking the Myth of a Software Labor Shortage . In a few more years, you probably will want to transition into a lead design or managerial role, so this track is reasonable (especially if you want to become say CTO of some firm during the next upswing in the tech sector).
There have been several remarks say that you should continue to code. It is probably not a bad idea to continue coding, however, being a good leader/manager DOES NOT mean that you need to be a great coder. It helps to win the engineer's respect, but if you follow sports, you know that the best coaches were not necessarily great athletes in the sports they coach (e.g. Bela Karolyi in Women's Gymnastics) but they do have to understand both their people and the jobs that they do.
The most important thing is to ride out this current weakness in the economy and position yourself for a profitable and successful ride in the upswing. Don't get trapped into obscure or uninteresting technologies by chasing short term rewards.
HELL YEAH!!!
I've just been tk'ing in Return to Castle Wolfenstein and it was Fuuuuuuuuunnn.
The tide has shifted. The first few posts mocking this guy got modded down as they were an affront to the arrogance of slashdot...but now an even more oppresive force has taken over - group thought (another hallmark of /.)...you've gone from parriah to guru in ten minutes!
Beware of playing too much Quake3! That ruined my career. Now I am unemployed. (sigh)
Developers: Coder or Architect?
Can you be an architect without being a coder? Don't think so.
Seriously, an architect is just an upgraded coder. Fatter pay-check, fatter office and fatter slave-staff (not reffering to MacDonald coders.)
Look a monkey!
titles are meaningless and the fact that you have gone all over the map by 33 simply reinforces this, particularly in the self-important, amazingly smug bay area, where everyone is a genius and a visionary - even the ones out of work.
Things I'd recommend (being 28 and in the same position myself):
1) Leave any arrogance you have at the door. People 20 years older than you may not have your raw talent, but they have a lot of wisdom we 20-somethings don't have yet. Arrogance is a sure way to draw resentment from your seniors.
2) There's nothing wrong with unscalability when scalability is not an issue. For example, don't bother architecting your Web application to scale to millions of users when your target audience is only a dozen. New architects tend to overkill every solution.
3) Don't get religious over OS, dev tools, etc. However, don't be too agnostic, either. If your shop is very Windows-based, don't try to revolutionize it with Linux - and vice versa.
4) Document, document, document. UML comes handy here.
5) Ask people about their concerns - just because you're the architect doesn't mean you have to be all-seeing. You just have to be smart enough to know who can help you identify and think through problem areas.
6) Prototype, prototype, prototype. Hack the code if you need to - it doesn't have to be pretty.
7) Architecture != Code Organization. Architecture can affect code organization, but it is a separate issue. Two projects with the same architecture can have completely different code structure. Don't get caught up with code organization. That's an issue to tackle later.
8) Read books about software architecture. It may seem beneath you, but it's definitely worth it. It certainly cannot hurt, and mainly it helps to cover your ass in case you need to defend your decisions. I've had to write memos to defend my design, and it's very easy to do when 3 or 4 famous books agree with you.
The first thing that ran through my mind after reading your post was "been there, done that" or at least I thought so at the time. Some of the best advice in response so far has been along the vein of "don't get cocky". It really doesn't take much to get that label of primma donna or 'difficult to work with' and it's damn hard to shake.
The economy is going to hell in a handbasket and some of the first people to go sound just like you. Fewer years of experience coupled with a higher hourly rate make a good target. I'm not saying it will happen, the odds just favor it. FYI, I'll grant you I might be biased as it just happened to me.
The longer your work on a system fixing problems, the more people come to you when they decide to alter it. It's a natural progression and no big deal.
It sounds like things are going well for you in the office. Keep doing what your doing and make sure you continue to produce results and that your happy doing the work. With those two things in mind, you can't fail.
Career direction doesn't matter until you come across the ideal job, and go "Wow! I want to DO THAT!!!" There is not a single person here that will be able your office, your environment, or what you will need to do there to succeed.
~~ What's stopping you?
Sooner or later a project will hit crisis. Since the heaviest load of architectural work (for an even moderately well-planned project) is near the beginning, and the crisis point for most projects is near the end, you can keep your skills up just by involving yourself in the crisis coding near the end of projects.
:)
Of course, it's always possible that your development organization never has crises, but if that's the case then you are so blessed by the deities of programming that you will never need to worry about code anyway
--G
It's stories like this that cause opensource to work.
He's climbed up the corporate ladder and found he's in a spot that he doesn't exactly like, and would like to change careers to begin "in the middle" again.
I'm in the same spot. At 24 I'm the programming manager/lead developer for a large content site. If I climb any further, I won't be doing any programming what-so-ever. So I'm staying at my current level. Of course the human being can't just stay at one level, they need to grow. I do this outside of work. I'm working on 3 open source projects, and it's keeping me busy and happy. I find that as official "middle management", you have a lot more free time on your hands. What better way to fill the gap than open source?
I didn't say it was worth anything. But titles aren't meaningless. I just want to make sure that a title is descriptive of the work I do, and hasn't been seconded by a jerk who wants to make himself sound impressive. It gets harder to find an accurate description when people call themselves something as a means of job promotion.
The above post was not a troll, the ARTICLE was a troll.
BTW, nicely said.
[From Seinfeld's episode #103: "The Shakeout"]
George: I'm, uh, I'm an architect.
Vanessa: Really. What do you design?
George: Uh, railroads, uh...
Vanessa: I thought engineers do that.
George: They can...
Never totally stop coding.
In any project that is worth having a team and an architect, different parts of the code will fall on the spectrum between 'interesting' and performance/reliability critical all the way down to cut/paste boilerplate, code by numbers.
Assign or have assigned to yourself some part of the former code. This will help to keep your skills sharp as well as provide insight into the problems being faced by other members of the team. The tough part is deciding on how much code to do yourself. Taking too much will sap the time you should be spending on overall design, and will deprive other coders of the challenges needed to grow and remain interested in the job.
What you see when you move from a more in depth position (network/systems/software engineer) to a more abstract position is a requirement to understand and deploy/spearhead solutions to solve business "problems". If you are lucky, you are a revenue stream and life is easy. If you are unlucky, you are eventually required to support Micro$oft products. (grin)
The basic priciples descibed for software engineering always apply, but it's my opinion that the cycle is much more fluid at a higher level. (More people to appease, more requirements to understand.)
Raw talent is good to have, but the soft skills to interface and move projects that invariably cross business units forward become quite important. Don't worry about offering specific advice to folks; they are prolly more interested in following the steps of a high riser. Make sure to keep adept at the technologies that made you successful (DBA/software/networking), but also try to consider solutions with different types of technologies.
Do things that make peoples jobs easier, look for patterns in problems, look for the same in solutions. Try to learn from people that have been there, use newgroups, discussion forums, friends to your advantage. Be good at being a leader; don't be afraid to say you fucked something up when it happens.
Take responsibilty.
--Adrian
As much as I wish I could assure you that you can be an architect for the rest of your career, from my own experience I have to advise you to do otherwise. Like many who are responding to this article, I, too, have been an architect.
;)
Currently, I work at a high-profile software start-up and guess what? No one has the official role of architect. We have a very experienced, very successful development and management team, too; apparently, they do not see granting someone the title "architect" to be beneficial to their success. For the trolls out there: the lack of an official architect will not be a reason a company like mine fails.
Others replying to your article have mentioned that it is important to like what you do. I concur, and that will always be the best compass for your career. But, having said that, I think the role of architect may indicate that you are currently in an anomalous position: chances are good you may merely be smarter or more capable of viewing the big picture than everyone around you. However, what if you were in a different company, or working on a different team? You may find that you are just barely keeping up. I contend that in a different environment, with others who may have skills to match or exceed your own, you may actually be more succesful as a developer than an architect. Therefore, don't pigeonhole yourself unnecessarily.
Further, nearly every successful architect that I have ever seen eventually succumbs to the need to become a manager. It's just part of the natural order of business: in a good company, those who lead and mentor need to become managers because they are best suited to tending to others, to steering the ship. That doesn't mean every manager is good as a leader or mentor (I've met my share of pointy-haired bosses, too), but invariably every good architect finds limits to their influence as an architect--and discovers that bearing a managerial title can actually increase their effectiveness.
Or consider another dimension: maybe it's not what role you should play (developer or architect or manager), but perhaps in what type of industry you work. Architects can often be much happier as a consultant, either for someone else's firm or their own; it is difficult to remain satisfied in a staid, old-line firm where 70% of the challenge is keeping ahead of maintenance.
Having only relatively recently passed through the same dilemma you face, I encourage you to understand the simplicity of the choices as you perceive them to be contextual. I, for example, chose to move on from a role as an architect and individual contributor, to accept a role as a director and department head because I understand that I had too many skills (such as a knowledge of the business, how to work with customers, and project management) that would have evaporated had I not made the transition. Of course, there are other skills I now have the chance to learn, too: how to *really* please customers, not just once, but on a regular basis; how to design an organization; how to architect systems for an entire company rather than for a single application; and (trickiest of all) to motivate, encourage, and develop the careers of my staff, especially when each one of them may have an inkling of their own desire to be an architect!
Ultimately, though, I did make my choice because I understand that I can apply the same skills that I honed as an architect (and many others I learned along the way, including some new ones), but on a much larger canvas. It would be a loss to yourself and to both your current and future companies if you only allowed yourself to be an architect. Strive for those positions that allow you to have a stronger impact, if you are really the right one to be making that impact. My decision to become a manager hasn't at all changed who I am or what I like to do. I still architect a great deal, frequently when my own architect is elsewhere deployed.
Remember: try to understand your dilemma may be contextual; that continuing to be happy about what you do is the best guide; and that you owe it your peers to impact your organization in a way commensurate with your actual skill. You are just at the beginning of your career: just wait till you see what happens next.
I can't tell you how many hands-off architects, project managers and high-level technical staff I see coming through my office these days. If you can't make a meaninful hands-on (code) contribution - particularly with "hot" languages you're simply less valuable to most employers in the long run. Architects and PM's are the first to get cut in tough times. Be very careful.
www.roytalman.com/rustin.html
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?
A bullshit artist too.
Remember that architects work for developers. If an architect doesn't make the developer's job easier or successful, then the architect has failed. If that includes answering some questions from time to time, that's all part of the job. You've just moved your fate from your hands into the hands of your developers.
;)
Same it true for managers. Sometimes it's easy to forget that and become the architect/manager that causes the downfall of a project. A wise man once said, there are no stupid soldiers, only stupid generals.
Just make sure your career path is the path to success not a setup for blame and humiliation by the people with 20 years more experience who know that the project isn't viable in either a technical or business sense. Keep in mind, you don't stay employed for 25 years and not learn to steer clear from icebergs...
Now isn't that cynical
At my company developers are called "archtiectural engineers." We also have full-time architects that *don't* code which are like project managers. The screwy thing is the coders ("archtiectural engineers") are supposed to leave their individual fingerprints on their projects, whatever that's supposed to mean. In the end, it just tramples on the domain of the architects leaving everyone scratching their heads wondering who's doing what. It's sort of like a "doctor-nurse." Makes no sense: you're either one or the other, not both.
The engineers should simply be called that and should build out what the architects design, not try to design and build their own projects.
$6.21 is the number of the beast before sales tax. Meh.
you are just the knee-jerk to the knee-jerk. what kind of a "leader" comes in here looking for advice? did patton ask the boy scouts the way to germany??
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.
Interesting. The only place that I personally have seen XP in place was this one group at a Naval Warfare Center. They seemed to like it, especially for newer programmers.
Oh, wouldn't I like to do this!
The problem is that in Sweden, where I happen to live,
you get fired immediately if you tried something
like this, unless your main job was way outside the
IT business.
My solution? Full time consultant.
Marine Biologist.
-- Sigs are for losers
I suspect that you will find, as I did, that the principal new demand is for breadth as well as depth in your technical knowledge. I know lots of Unix and C-oriented development stuff plus some networking, but there is a gap between that and devising the complete architecture for a website exposing previously internal business processes of a company with millions of customers. Depending on the nature of your organisation and products, you may also need to know a bit about third-party products in various market segments (i.e. for this bit of functionality we drop in product X and allocate Y man-weeks of effort for configuration, interfacing, deployment and support, insteasd of coding that part ourselves)
Things I have found useful are
- Know what you don't know - and figure out where to go for the expertise (e.g. who makes the best SSL accelerator / load-balancing switches? - I don't know for sure but I know who to ask).
- Consider a range of options - you haven't really done the job of architectural design justice if you have only considered one main approach. Even if it is the right approach it's good to show that it's right by comparing it to alternatives you considered.
- Build/discover/create a peer group of software architects. With software development & bug hunting it often helps to explain the problem - sometimes you stop in the middle and go "aha!" and rush off because you have figured it out. Architecture can be very similar. Watch out for the look on your peer's face that says "Why are you doing it that way?" It might mean that you're barking up the wrong tree, but it also might mean that this element of the solution will have to be carefully explained to the client in terms of its advantages, otherwise they won't go for your proposal.
- Scope control - learn to negotiate the scope of the system. This was probably mostly out of your control as a developer, but as an architect this can be one of the most powerful tools you have. Tight/clever/detailed/thoughtful control over the scope of the system to be built can lead to great improvements in reliability or reductions in development time - i.e. push those stupid features that take 10x the effort for 10% of the benefit out of scope. The sales guys won't like it if you say "it's too hard" but they'll listen a lot better if you say "if we remove that from the scope we reduce the delivery risk (and hence the risk to the customer as well as us) and increase our profit margin". They like that wording a lot better. You may have to phrase it as "let's defer that until phase 2 because..." of course.
Because of the wider scope of your role (i.e. responsible for the design of the whole shooting match) you may find that you need to make decisions - in principle - about things which you would not have had to code yourself in your previous role. At least learn a bit about all that stuff. Depending on your role, this may mean learning more about middleware, distributed database architectures, wiring, user interfaces, credit vetting, image processing, or some other thing you don't already know about. Figure out what this is and who knows it.Undestand the capabilities of the developers who will write the code. This is important when considering multiple approaches. There is no point basing your system on J2EE if it has to be delivered in 3 months and nobody knows Java. However, you should always know when to break this rule - for example, if you have to transfer lots of files, use SCP or Perl's Net::FTP instead of coding it in C.
Sometimes you will need really detailed understanding of a specific thing. For example, there are things you just can't do reliably over NFS. Figure out what these potential pitfalls are.
Again depending on your role you may find that you need a bit of training in presentation skills, team leading, sales techniques, product selection in some market area, or various technical things that previously weren't your problem.
Talk to your peer architects. Which approaches worked, and which didn't? Why? Which bits are harder/more expensive than people normally realise?
Not to brag and I never wood, but just to make this guy feel like crap, I got him beat by 9 years, Im only 19 and more then likely making twice as much money as he is... hahahahahah .... loser !!!! christ, the first thing I learned, was not to barg about where i am, be humble. although I am bragging right now, it does not count cause Im posting as AC......
You will be working at McDonalds at age 30. I would start working on your burger flipping skills if I were you.
You were not "promoted" because you are good. It is to get you out of the way to bring in fresh blood that will work slave hours. The fresh blood will see how cool you are and want to be just like you in a few years. And so the cycle continues.. Code slave, hip management, McDonalds.
Even junior programmers these days have to architect large systems because of poor leadership, mismanagement, and dead wood in the department. Its not suprising to see even the most junior underpaid programmers designing important components with no input from above. If this is part of the junior or entry-level requirements, then the compensation should reflect that, but it doesn't. And if the project fails in some way it's the newest, lowest paid guy's fault. If something goes right, PHBs and higher-ups try to take the credit.
If you are after a job title that will guarentee a good job for life, I'd like to suggest.
"one who figures out what to do and does it"
I know many, many hiring managers willing to hire anyone who has been legitimatly granted that title at the drop of a hat.
So many folks have one skill or the other, finding a person with both skills is a rare find indeed...
Oh, yeah, silly tech-titles *ARE* meaningless, successful companies learn to ignore them for hiring and promotion purposes. Unless you are caught up working for one of those *unsuccessful* companies. If you are, then by all means, seek out the best sounding title you can. You'll need it when looking for your next job.
I could care less what my title is as long as they continue to pay me more than I'm worth (I don't think I could make a living if they payed me what I'm actually worth). Everyone is replaceable, and getting a management label is something you don't want to get stuck with when the economy tanks (as it is now).
/. is considering changing their name to "suckslot.org" in the interest of maintaining credibility with their new more suckier user base....
Are you sure you aren't being transitioned because some of the other coders complained that you can't code yourself out of a box and they collectively felt the project would have a higher chance of success if you stopped coding?
Nah... coders wouldn't do that to just anyone, only someone special...
How about learning to not sound like a jerk? You come off as one who is just looking to make their next strategic move. So do whatever it takes to make yourself look good in the eyes of those who you think actually matter to you and your career and you will be just fine.
If you really want to succeed, you need to hone your technical skills, develop strong relationships within your organization/sphere, and also balance the line between "in charge" and "egomaniac" and "overly democratic". All this is really an exercise in wisdom. Learn when you can. Carefully apply what you've learned.
Stop the brainwash
(quote) After listening to this guy polish his ego in front of us for two paragraphs, I can say with certaintly that this is one individual that I would in fact want tied up in meetings. Endlessly. (end quote)
It is said that meetings are proliferated by those who are best at putting on shows.
However, I have met coders with huge egos who still like coding. They just brag to other coders most of the time.
He did not have to mention ages, however. That was unnecessary.
Table-ized A.I.
I believe that you aren't wise enough to take on the role of anything other than giant foam finger maker. I am not impressed with your list of accomplishments. I rose to your level of bullshit at the age of 24 - without a college education. Do you know what I've learned? I've learned that there will always be someone ready to come out of nowhere, and with great brevity I might add, to deflate your ego. You really must learn to work with people and be the best man that you can possibly be. Measure your worth by Cliff's potential, not the national standard, which is way low I might add. You think that because you've tasted some success prior to getting that AARP application in the mail that you're special. Guess what, there are people just like you all over the world.
These especially apply for touchy-feely jobs like "information architecture," but can be applied to any job within McCorporation.
1. Clearly define yearly goals. Make sure they're realistic and qualitative, not quantitative. Include in your goals learning something you are interested in. Have your manager sign off on them.
2. Touch every project you know of that's related to your work. No need to get heavily involved. Look at the project, know what's going on, know the technology, know how it will affect your work. Write an opinion, recommendation, or just a report. Make it short and high-content. A pretty picture never hurts. Make sure to email it to PHB, as he probably won't remember to look at your intranet site. At least then his sec2 will have read it. Do this at least once mid-way through each quarter.
3. Write quarterly reports. Trump up any work you've done on popular projects, keep work on politically sensitive projects to a few lines. Again, email to PHB. This time he'll read it. They always read quarterly reports.
4. Request at least two weeks of training a year. Make these requests at least two months before you want to go, or within ten minutes of hearing your boss mention extra budget money. Include summaries of what you learned at these training sessions in your quarterly reports.
5. Request to go to at least two conferences per year. Again, write about what you learned at these conferences. Include in reports.
6. Write a yearly report and hand it over in November, along with next year's goals. Make sure your yearly report shows that you met or exceeded each of your goals.
7. Don't piss too many people off.
-----------------
So that's it. Do this and you'll be an information architect for as long as it amuses you. I'm serious.
Now if you need some ideas on training and seminars, and the general work part of being an information architect, just go here: Object Management Group - you should be able to take care of the rest here.
Good luck.
Ummm, yeah. None of the projects I've been involved in have ever had a 30 hour death march leading to implementation. Twice. In one week.
Seriously though, excellent point. Thank you. It's something I've done unconsciously for the most part, but will try to keep more conscious of in the future.
The truth about Scientology, Xenu, and you: Operation Clambake
As a recently-layed-off Senior Architect, I'm here to warn you about the practice of "fleshing" or "purging".
On October 12 I delivered the prototype of a system that involved JSPs, fat Java clients, J2ME wireless clients, JMS messaging, XML, etc., etc. Complete with designs to justify the use of Queues vs. Topics, stateless session beans to provide pooled access to the JMS, etc.
My boss said thanks. And then explained to me that since the comany was transitioning from R&D to maintenance and sales, the services of the people who'd designed the company's systems were no longer required, here's two week's severance, sod off.
The maintenance people are still in place. The architects and senior developers are looking for work.
I know that karma will come back to bite them in the ass, but the present is still a bitch.
668: Neighbour of the Beast
Submitting circumstances to public forum, and being able to assess viable conclusions is a *key* and vital skill required of anyone who desires to manage.
Never let yourself be governed by those who chose to run from hypocrisy or contradiction.
Garner this skill wisely, though. Don't capitulate to "collective think".
As an engineer, alway seek a solution that *solves* the problem, and never let the prejudices such as those stated by this troll to sway your judgment.
A good architect knows no bias other than a desire to get the job done, and done properly.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
Seriously my career adivice would be..
Get a girl/boy friend
Jump on a place and travel for a year using some of this money you've accumulated from being a hot coder. You should be visiting places like russia, iran and china - anywhere *interesting*
Get drunk with people you shouldn't - live to regret it.
Take casual job in a country where you don't speak the language - or one where you do but don't understand the culture.
etc. etc. etc.
The point? You've obviously been so keen on you 'career' you've forgotten what living is for. The USA economy is going into major recession and at the moment you are just another interchangable piece of cubical fodder. Go and grab some real life exerience while you still can, because in the long run it's what you learn and apply from that which is going to make your life and career worthwhile for the next 40 years - not being given some ridiculous company job title
Designing houses is a much more honest profession than programming. Go for it!
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.
Well, who said that?: "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" Baby, you have some problems communicating with other developers in addition to your gigantic ego. In real life you are neither developer nor architect :)
>
I haven't yet read all the posts, but I'm sure there are hundreds of senior developer/engineer/architect types here all ranting about themselves... and likely wrapping up with a "watch your ego" at the end.
I'm a fat head just like the rest, but here's some advice from somone who has worked in companies from 3 to 320,000 -- just stay creative. Screw the titles and ego. If you are a creative thinker who can solve problems you'll do well. Like to code? Then keep coding. Like Visio/Rational Rose? Become an architect. Want to do both? Then do both, don't let a title pigeon hole you.
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/
Career wise, sure. "Architects" gte paid mreo in many firms.
OTOH I have little respect for Archietcs who don't code (and eys I've done Architect duty). Its too easy to design theoreticly pure stuff that won't work in the real world unless aprt of your brain is actively engaged in "how will I build this" kidns of thoughts.
Pure architects IMO are useless for much more then spewing marekting documents. Keep your hands in the code to soem degree and make celar to management that this is the only way to getr eal value out of you.
Unelss you WANT to become a "Marketecht". Some of those guys get paid very well by large firms, but I dunno how they can loo kthemselevs in the mirror in the morning...
Dude, do you what a vagina is?
I believe it's a custom part of the female model of homo sapiens. It serves two purposes, one being an input port, the other being an output port. It functions primarily as part of the reproductive process of the species. It was designed for maximum flexibility, yielding to objects both small (like your penis), and large, such as a baby. Typically, the output method of the vagina forces it to operate much closer to maximum spec than does the input method. Like all body parts, it requires regular care and maintenence. Although it is capable of sequential serial input from multiple devices, the controlling system generally prefers utilizing fewer input devices over a longer term. The input/output ratio is heavily weighted towards the input process, as the output process uses many more system resources, both short and long term.
The truth about Scientology, Xenu, and you: Operation Clambake
One of these days you will wake up.
Dude, you are being setup to fail, run fast run now!
I agree... it seems that if you stay at a company long enough, and they spot you doing good development work, you get "promoted" to Architect or Manager.
I think there is some logic to it though. Flagrant egotism aside, I've been at one company now for that magical amount of time as a developer, and now I'm being goaded into becoming something in the grey area between architect and manager... and I don't like it!!!
There is a point to the madness though. Good developers are often efficient at what they do. It stands to reason that if they can alot themselves ample work and then complete it in a timely manner, then they should be encouraged to help others do the same. And eventually, they start getting paid to do this. Stated without proof, I think Architect skills are somewhat of a corallory to this as well.
I feel comfortable saying this, because with enough experience, and if I learn from my mistakes, I think I can help others be good developers as well. And isn't that the whole point of being a manager/architect?
What is with computer sientist that they need to steal titles from other professions? I'm mean what's next? Are they going to be calling themselves Computer Doctors? Or perhaps a Software Accountant?
Totally comprehend that. I deleted 40,000 lines of C code from a system once in order to make it function. Rewrote the removed functionality in approximately 4,000 lines of C and imbedded SQL.
The problem was that management allowed the code to reach such a state. But thats what happens when management only understands SLOCs and fails to reward efficient design and coding. And of course, not doing peer reviews.
You are being MICROattacked, from various angles, in a SOFT manner.
About a year ago I went through this transition at a startup (FYI, that startup is no longer there) Here's a few things to look out for:
1. Many people inside a company may have different ideas of what an architect does. If you describe yourself as one, there can be all kinds of misperceptions to deal with.
2. In many companies, architects are considered a luxury item, so when times are tough they are rarely hired.
3. You will get age resistance, since most architects are older than you.
4. The definition of architect is very fuzzy. At some companies like Sun Microsystems, Architects have Phds and 10 years experience on average. They don't really lead a group, but primarily do specifications and handle
meetings (and occasional coding to stay fresh). At a startup, they are you and me. They could be asked to do almost anything from test planning to project management in addition to specifications and the like. Depending on where the managers/officers of the company come from they will have a different expectation.
BTW, don't take too much guff from people about being arrogant. I've led 40 somethings before too.. it's not that we are better.. just different. In my experience the 20 year guys don't want to deal with leading and are on their fourth or fifth primary language so I don't expect them to remember the details like I do on my 2nd.
Oh another side note, don't code on the project you are architecting if you can avoid it. Writing minor stuff or interfaces are ok, but not serious long term coding. I know a lot of people are telling you otherwise.. but it can often lead to odd, ugly conflicts of interest and time. What's easier to code is often not the right answer architecturally and with deadlines as they are.. well you see the problem.
DescSuit
The author is asking about whether he should transition instead of how best to transition.. I know for me it's always easier to figure out how than is it right for me.
I've known more than a few programmers that have led themselves to a job hell by going for the "next" step in their career. People that should never have been managers or architects being pushed up.
So I guess my suggestion is, take care, focus on what it is you really want to do, don't just jump to the next "level" as decided by someone else.
DescSuit
Also, it's as much about people as it is about software and hardware. As you modularize the design to break it into parts to delegate out to different groups, you're dictating the interfaces which those groups will use to interact with each other. It's somebody or else's law that software resembles the organization that created it. And it's true. You can extrapolate the organization that created the software from the software itself without ever having visited the institutions that created it.
Anyhow, hopefully you will become adept at architecting designs that encourage a cooperative and synergistic environment leading the software that is the same.
If you are so damned smart why do you need help deciding what the hell you are going to do with your loser life?
I'm a hansom lad who enjoys horseback riding and driving fast in my brand new BMW. I winter in the French Alps and have my own vineyard in California, but enough about me. I need to know what's more important a cure for cancer or world peace? I'm so smart I just can't make up my mind.
I would like more insight from the ladies.
My number is 1-888-569-9087.
Chow!
As a real-life Architect (bricks and mortar), I take exception to software developers appropriating the name of our profession, and what's worse, using it as a verb. You make twice as much as us, you have more job security, at least find your own word!
After reading other comments, I think many have jumped to the conclusion that the person soliciting info wants to become a full blown manager. I'm working at a place where there's a project manager and a technical lead. The project manager deals with time cards, upper management, meetings, while the technical lead deals with the system architecture and focuses on high level technical issues.
I personally lean towards the technical lead side of things and tell my supervisors this as well as in interviews. I let them know I'm not interested in doing time sheets or listening to other employees crying on my shoulder because of some company problem.
Right now I do architecture (share duties with technical lead), coding, and maintenance all at once at a small company. Typically, you can do this in smaller companies where you wear multiple hats becuase they cannot afford to load up on one person per role. In larger companies that I've worked at before, you are usually (not always) shoehorned into "a role" and that's that.
It just boils down to knowing what you what out of life and career, letting others who are responsible for you know this. Don't be afraid if your company isn't comfortable in living with this. If they don't like what you're telling them and if your good, you can find a better fit elsewhere.
The problem is YOU have to figure out what YOU want prior to acting on it. Do you want to move up the "corporate ladder" (if there is one)? Would you be comfortable there if you don't and someone else does? Do you want to stick to the technical side of jobs? How much do you want to be in control of things?
What you need is an introduction to Nihilism. The core concept with regards to you is this - for your entire life you have been told that you are special by your parents, teachers, religious leaders, and most of all, anyone who has marketed a product to you (these people are more to blame than any of the previous).
This has resulted in a collectively inflated sense of self-worth amongst Americans, and a total absence of modesty. You believe you are worth something because your Mercedes tells you so.
Now wipe away all of this. Break down the core concepts of who you are and where you are in the world by destructing it and laying it before you so you can assess it without your own bullshit getting in the way. You'll find you aren't the smartest, biggest, fastest or best anymore. You'll find that there is someone who can code you under the table even in your tool of choice. You'll find that there are people who are effortlessly better than you in pursuits you have dedicated your life to.
Knowing all of this is the payoff, not the letdown. You'll find the liberation in shearing off all of the aggregated horseshit the "I'm okay, you're okay" crowd have jammed down your throat all of your life. Maybe just maybe you'll see things for what they really are starting with your self
If you don't mind my asking, how did you break into the field in the first place? I don't think I have the professional experience to be credible in that role yet, certainly in the current employment climate, but it's something I've considered as a longer term direction. The big barrier isn't so much my skillset or willingness to learn, which are developing OK, but rather the "foot in the door" principle. How did you get those first few jobs, so word of mouth could start to spread? Any background would be welcome. :-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Inject 200ml of Ketamine, don't fall in a swimming pool, and after about 45 minutes you'll know what to do.
Me Too. I'm so smart they made me Vision Master, Conductor of Out of Box Thinking. It really sucks because, I like work with people 50 years older than me. Those are like my grandparents d00d! And they're always like "No, we don't need to upgrade the production servers to kernel 2.4.13. They run Solaris.", and "Maybe batch scripting is not the appropriate ecommerce solution.", and "Please change your password, 'p4ssw0rd' is not acceptable. No we won't give you root." Shaahhh. Whatever. Anyway now I'm like in charge of everything and can add Applets and JavaScript to the corporate website. But should I really print "Vision Master, Conductor of Out of Box Thinking" on my business cards, or just go with "Elite Funkelic Code Foo Sensei"? Damn, I can't wait to cash my stock!
I am a young software architect, promoted a few years ago (when I was 26). The transition from lead developer was difficult, mostly because I resisted the fact that 'architect' is really quasi-management. It is a role that requires gobs of communication, documentation, and strong leadership skills.
The key, I find, is to somehow remember your passion for the role of desinging and preaching systems to a group on a regular basis. I look for things that remind me why I like coding, design, and bringing good sense to the people I serve. And remember, you serve the entire company; your role is to make decisions that will enable the business, and be within the abilities of the developmers and testers.
Ignore the fact that you are younger, it will only undermine your authority. Remember to excercise your authority when it is important, and to let the little things go. And, humility will buy you loads of respect.
Most of all, dream constantly about software design, etc. ... as innovation is the product of passion, and borderline insanity. And, never stop learning. Don't let a month go by without reading a dozen books and implementing at least a handful of things based on what you learn.
Will you stop coding? Only if you want to. You are now a leader, so if coding is essential, then you direct your copmany to allow for your position to code. I set asside 10-20% research time (coding/reading), and I prototype around many of the new technologies we add to our product regularly. And, you are Free to contribute to the GNU project in your spare time ;P
mx
If you are as proficient as you think that you are you should start your own company. Top of the class? In any other role you will be working for people stupider than yourself.
You may want to stop being proud of your quirkyness and grow up a bit. For starters, you can stop playing with your legos on the job. Keep them at home with your barbie dolls. Only been with the company for one year? What happened to the previous company? Got sick of your shit? Most likely the unofficial reason.
Wow, sounds like your a talented guy going places. A few thoughts from the peanut gallery: Many projects have architects but no architecture. Software Architects need to be part systems engineers. A smarter guy than me wrote that 70% of all software defects are requirements based. This means that figuring out what to do can be more important than being a rocking coder. Technical Architects take on the jobs that others may not be able to. Fight the fires that need fighting not what you find personally amusing. Architects never say, "I don't know how to do that, so its not my job to fix it". They say "Let's make a plan and figure this thing out with Bob, and Jane,...". I like to do Horizontal Prototyping early on. Creating a fabric for your less experienced team members to flush out can really help in Distributed Realtime/Communications stuff. (But I'm sure that's not new to anyone). Parallelism is the key to meeting deadlines. Keeping your team members moving can , at some times, be more important than sleep (provided your employer has good / and hopefully free coffee). Performance models are a hard sell, but they can save your butt. Might have to do on your free time. Dale Carnegie wrote that 20% of what you learn is technical, the other 80% is people skills. He was right.
camusflage wrote: Ummm, yeah. None of the projects I've been involved in have ever had a 30 hour death march leading to implementation. Twice. In one week.
Bad management, at best; goofing off till your project is at the point of crisis so you can show off, at worst.
Seriously though, excellent point. Thank you. It's something I've done unconsciously for the most part, but will try to keep more conscious of in the future.
As the Architect you can gaurentee that there are many of these sort of opportunities in the future. You'll be hard pressed to find coders who know how to implement your brilliant plans. Yes. More projects in "emergency" status in the future. Have a good time creating a loyal workforce.
We use these terms a bit different. First of all none of the architects belongs to the operations/production branch of the company. They belong to sales/marketing.
Why?
Because their job is not to build things. The architect works with a business developer (read: salesman) in the preparation of the proposal, follow-ups, etc. The main function of our architects is to make sure we sell things that can be done, not things that sound cool to both the business developer and the client.
Our architects are marketroids that happen to be good planners and are technically oriented. They cannot write one line of code but they are very well aware of the benefits and limitations of say, use a database-backed website at a corporate level, etc.
I am not saying our definition is right, just the way we use your title to describe the techies that work exclusively for the marketroids.
Pedro
----
The Insomniac Coder
Yea. I've not done any moderating in some time. But now that I have a reason I'm going to sign up to be a moderator again.
So why are you here? To try to puncture the egos of annoying and pimply young geeks? You know it isn't going to work, any more than my responding to your ongoing trolling will work.
If you've spent years studying and can design buildings, and a professional body has decided that you are good enough to do that for a living, then you can call yourself an architect.
The same goes for engineers, you've got to have the knowledge to put together an "engine" (or machine in the old form of the word) of some description, and be certified by your peers.
Put "Software" in front of the name however and everything changes - you're a software person working on a specific aspect of software. Leave the "software" off and you have a sitation akin to a Phd in divinity calling themselves "doctor" all of the time and letting people assume that they are a medical doctor.
I'm still a bit miffed at Microsoft selling the MSCE, which lets all kinds of people of various skill levels (eg. why can't you just put the name in for the dns server instead of this big number?) go around calling themselves Engineers.
I'm waiting for the next step, M$ certified judges. Selling a title like that would upset a few people.
I have no degree and make an excellent living writing code. Don't let anyone define you by what pieces of paper you have or don't have.
Just be compentent in what you do. That will put you years ahead of paper tigers.
I have to ask this because instead of coming up with UML diagrams to describe what I typically call the architecture of the system, the "Architect" where I'm currently consulting instead tries to specify a blending of a number of implementation patterns - which he's never actually seen done - that all developers are supposed to use. It may not have been a problem except that the project had a definite time limit.
So I'm looking for a more formalized definition of the responsibilities of an architect.
I love the following quote from BredeMeyer Consulting:
"Too frequently, "architect" is a promotion offered to top-notch developers in an effort to retain them. Unfortunately not all superb technologists have the broader talents and skills that make them good architects. Still, the title raises expectations in the "architect"--and the rest of the organization--that architectural responsibilities are associated with the titled position.
This can generate a lot of conflict for a strongly technically-oriented person who is suddenly overwhelmed with organizational politics and communication demands."
The only thing that I'd add to this is: if you have an excellent developer who you stand to lose, try creating a surgeon team around her. I first read about this technique in "Mythical Man Month" and used it with one of my "gun" developers. He didn't want to manage or even mentor staff. But he just wasn't productive enough on his own because he still needed to do unit testing and requirements work etc.
So I created a surgical team of 7 people who "supported him" (the surgeon) doing requriements updates, testing, backup dev and project management. I know this sounds stupid, but it worked really well... everybody knew their place: working FOR him. But not reporting TO him.
We launched 3 successful projects in that fashion.
Patrick.
Having read all the noise and the posts, it seems apparent that you like to code, keep this in mind when moving up the food chain as the higher you go the more removed from the code you become. Now most small companies will still require you to code, but larger organisations will consume all of your time in meetings, which political correctness will require your attandance.
This has been my experience, and I'm now happily back to being a JAP(Just Another Programmer).
Cliff, It depends on which field you are in and what your desires are. I would say a 28 year old maybe able to be an architect if they are doing applications programming (Java, XML, etc.) However if you were doing kernel design, network stacks, I'd be a little skeptical. Well, there are those few that are truly brilliant :-)
You might want to ask yourself also what you want to get out of your job. As a former architect myself, I found the job tedious and non-rewarding since all I did was push documents into engineering, educate management, and attend customer meetings. Your experience may vary, but what I just mentioned are part of your duties from now on. I went back to coding.
Anusflange queries: "I recently was transitioned into a humping egotist by my employer. I had been over emphasising my involvement with development and architecture, for some time. It appears my new duties allow me more channels in which to polish my ego. The company has agreed that I can use company headed fax paper with 'Software architect evangalist god' when I only have skills in notepad++. At not even 28 years old, I'm already a self-opinionated wanker and have people with twenty years more experience hoping that I have an accident on the way to work. Over that past year with my employer, I've expended much effort on absolving myself of any responsibity with other groups in the organization, sure to carry me far as an architect. Since I've already resolved that management is not a track I want to get into, whats my best way to masturbate in public? What do I need to do to make sure all the women in the office love me, and all the developers worship my ability with the DOS prompt, as I'll be spending less time in the bits and bytes? Any tips from those who have made the transition from development to architecture are appreciated, but more than anything, I'd love anyone who isn't as fortunate as me, both intellectually, and finacially, to know how well off I am."
Drink the Kool-Aid ...
Hell, I go to meetings like that every monday morning. My old management likes to bully its viewpoint onto the worker bees. Likes to use this meeting to have everyone hold out their own petard for inspection. Gotta love clued in management like this.
For the original poster, I have my feet in both camps. I do not wish to be a code-monkey though. My personal preference is to set the tone, the vision, and help make it happen. Just be aware of the aforementioned manager type. You may find yourself in meetings pushing off getting extra help when you don't need it, and then having to ask for the hundreth time why the resources you have asked for for months have not been acted upon.
If you go the architecture route, without being in management, you might have an easier time of the work. Just make sure your management runs interference for you. If they are not, teach them how. You cannot be bothered because the head of sales has a boner, and really wants to sell the thing now. If it ain't ready, it is going to do more damage to the customers/reputation by pushing it faster/harder/earlier, and comprimising design, than by taking the heat and delivering a good system.
Customers speak. To each other. Poor (or rushed) architecture will show. A sales persons commission is not as important as recurring revenue. Make sure your management buys into this. One off's suck, and supporting them is hell.
If they don't buy into it, then your management has some self destructive tendencies. Ought to reconsider whether or not working there makes any sense.
One trend that (for better or worse) has been building for the past few years is the building maturity of software as an engineering dicipline. We're not there yet, but in about 15 years some of us will be counted on to develop systems that will be verifiably bulletproof and someone will be sued if it fails. (We may look back at the 90's as the good old days when even high-school kids could make good money cranking out code.)
150 years ago bridges used to collapse regularly; even 100 years ago bridge collapses were not unusual. But today, we're building bridges that will be around forever. What happened? Just before the American Civil War, Civil Engineers got together and decided to become more professional. This also led to standardization of building materials and design processes. Yes, you don't see people building bridges and dams totally off-the-cuff, and it takes a few months to do it right. Today, most bridges have a signature of a certified Civil Engineer on the blueprints and you can guess where the lawyers will be looking if there is a problem.
In the next few years all the SW-CMM process stuff will become critical ( http://www.sei.cmu.edu/ ). There are a few highly organized projects deployed and becuase we're taking measurements we can show that going through all the steps does decrease costs in all phases of a project. With the dot-bomb contraction there's a little less pressure and a little more time to do it right the first time.
The group that will push this through are those who are today identified as (usually) Architects. If you have a customer who can't figure out why there's an Architect on the project who's billing at a higher rate than a coder and yet doesn't produce any executables (my current problem) you can go back and show how, by applying a dicipline, the resulting system will be more stable and usable (my current solution). And even a PHB will see that--developing the communication skills to explain (as best as possible) the latest neat-o blivet to the founder's son is the hardest part of the job.
Of course, I'm still coding. But as a previous poster brought up, it's only to help out in a crunch or to get something started and ultimately my code is maintained (or rewritten) by someone else within a month of my writing it. But actually coding a, say, JSP is the only way to grok what you can do with it.
And giveback? Mentoring that new kid or getting that old COBOL programmer to get with the program is easy. Getting your employer to see the value of process is valuable (start with a new, small project and collect some quantifiable measurements). We are going to have to build a solid environment that we can develop solid systems on, and I don't think it will come from any MonopolieS.
Don't dare call yourself an architect until you have gone to professional school four more years after your undergrad. Until then, push down your insecurities, and admit you are a coder!
You can't be serious. I feel that at 28 my skills are better than they've ever been! And I've been doing this since I was 8-10 or so. Sigh...good old trusty c64 (still have most of the memory map memorized after all these years! :) ).
There are many points I can make to argue that you get better as you get older. However, I'd think this was obvious. Do you really mean "30 and over the hill??" I know at 50+ your memory and stuff might start going...but 30???
Truely curious here. I never post to slashdot and this post actually got me to come out of lurkmode...
Ted
Code should always be self commenting
You're getting a lot of attention for your line about doing so well at such a young age. It's important to note that you might not be surrounded by super talent.
I worked for a company with about 1200 employees. I was a stud. People from all over the company would call and ask me for advice and usually I would come through. Vice Presidents asked for me to be included on projects when they were either failing or were just very important. My title (for whatever that's worth) was Senior Software Engineer at 25 years old.
Then I took at job at a company with 30,000 employees (Cisco). I became normal. I asked people for help and they often knew more than me. I put forth ideas and they had counter ideas that were better than mine. I learned a lot.
It's been a few years now and I'm getting to be a bigger fish in a bigger pond. Now I'm called a "tech lead" and I'm finishing up my comp sci masters.
The point of all this rambling is to make sure you know that you're quite likely not to be the supreme ruler of all things binary. Be sure to respect that people around you and recognize that many times, they'll be right and you'll be wrong.
Good luck.
That which does not kill me only makes me whinier
Did you think of that Patton analogy all by yourself? I practically shit myself when I read it. Of course, that could just be the booze talking...
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.
been thinking of something warm and wet for a while now, havn't you?..come on...you can share...hee...hee...
Dear Slashdot,
I think I am super hot shit. All these old programmer nerds are looking up to me. I'm like, not even thirty, and I'm obviously successful as hell. Sexy too. My question is, how can I inflate my ego more?
The Rams are a bunch of ram-monkeys. THe jets are the greatest team ever. FUck you.
Most of your time will be spent collecting requirements and reconciliating them. You have to polish up on your meeting skills and your organization skills. Learn to take notes effectively, and learn to ask the right questions. One good example is a book called "Database Design for Mere Mortals". I forget who writes it, but it discusses interviewing skills.
The other major slice of time will be spent writing pursuasive documentation. An architect needs to sell his design. You need to learn to write with the audience in mind, and given how your question was phrased, you have more to learn. You really did sound like a braggadocious snot nosed kid.
Finally, brush up on your presentation skills.
You already have (or should have) the technical skills, just keep those current. It is not important so much how some thing works, but what it can do for you.
And really, team lead is inconsistent with architecture. In many cases, an architect will work with the team, but not in a lead position. An architect doesn't necessarily need to be loaded with scheduling and human resource concerns. In some cases however, the roles are interchangable, depending on your environment.
Despite the fact that this is a troll, the comment bearing both "college student" and "software architect" begs my gripe... I am a Computer Engineering major at the University of Maryland, and I am keenly interested in software engineering from the architectural standpoint, and yet there isn't even an ABET-accredited software engineering major offered to undergrads. Computer science is not in the engineering school, as is true of some other Universities. I want to be taking object-oriented design and analysis, or "aplied programming" (STL), rather than an algorithms class. I also work for the Department of Defense in a software engineering role, so I have an idea about what I need to know for real work, and I'm not getting it, and neither are 95% of undergrads in CS or CE around the nation. Why is academia intent on not producing "applied programmers" rather than engineers?
I'm in a similar boat. My question to you: What do you want? Do you want to enjoy your job, make a lot of money, move high within the company?
If you like coding, architecture and other technical stuff and truly don't want to go the management route then keep your head down and do the tech stuff well. Don't worry about cultivating contacts in other departments. Offload the requirements gathering and program management and concentrate on design, architecture, development and implementation. Do your job well and you'll be rewarded and respected and left to keep doing the tech stuff you enjoy.
If you want money and position then cultivate those contacts, get some face-time with the bigwigs, make sure you're at those important meetings. Eventually you'll do less and less coding.
Once you figure out where you want to go you'll have a better idea of how to get there.
Picture yourself now as the kindly grandfather to all your developers. They're full of energy, but young and inexperienced. But they have a lot of good ideas too, and ultimately it's up to them to get the job done. (i.e. they have delivery responsibility.)
Spend a lot of time talking to your developers. Ask them questions like: "How do you think this should be structured?" or "Are there any new technologies you might want to use?" or "What do you think the most difficult part of this project will be?" or "Is there any piece here we could make reusable?" Keep the discussions going on all through the project. "What parts are you having trouble with?" "Did it work as well as you expected?" "What would you do differently if you had to do the project again?"
BTW You may know all the answers already, but a) that doesn't mean jack because you're not the one doing the project, and b) i guarantee you that the two of you will come up with better answers than either person could alone.
Also one of the secrets to good grandfathers is that they don't have anything to prove to anyone anymore - they've had their day in the sun. So if you still think you're still alpha male, don't be an architect, you'll just be a prick nobody wants to work with. Keep developing and prove that your kung fu's the best. But if you're ready to develop the next generation of developers, then great, go for it.
(FWIW I'm half manager, half architect, a good combo i think.)
A truly great computer programmer is lazy, impatient and full of hubris, says Larry Wall (developer of Perl).
I say you stay programming. Once you demonstrate laziness, you'll be truly great.
Anybody want a peanut?
I could go to Europe
Travel with my friends
I could blow a thousand deutschmarks
To get drunk in a pub with some Australians
Buy a giant backpack
Sew a flag on the back
Think never is enough
Yeah never is enough
You never have to do that stuff
Actully, I agree with you quite a bit... but there are lots of great life experiences to be had doing just about anything. You don't have to get drunk in a place where you don't understand anyone to have a Life Experience - you can do simple stuff like volunteering for things right in your own city.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
To address this post and the addendum you added on, I agree strongly with both points - development in the end is the most important task, though teaching is more important than even that!
I think the role of Architect as being like a gardener - you plant an idea/API/framework with a person or group. Then from time to time you come back to watch it grow, and see how it develops under the care of the group/person you have working on it - you can make suggestions for how it should grow and change over time.
But developing various systems and API's is only tangental to the real work. An architects primary goal should be to help others develop into architects as fast as possible. That's why I think a hands off approach is important, to let the other people learn as quickly as possible from the work at hand.
Thus an architect should be spending time shoring up weak areas, and planning ahead for how various projects under development can eventually mesh well.
In summary, architects can be very useful when they realize they are there to SUPPORT the real work, and to TEACH others how to provide said support. Managers would do equally well to remember the only goal they should have is support of real work and workers.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
And if it doesn't play well here, it isn't going to go down any better at work...
Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra
Joel Spolsky, another engineer-turned-architect writes thoughtful, entertaining, straightforward essays on these topics and other elements of software management based on his experiences at MSFT (regardless of your opinion of their business practices, they are certainly successful at orchestrating large, complex software projects) and, more recently, at his own company.
This stuff is such good reading that I've converted most of it into Plucker format for browsing on my PalmOS device. You never know when you'll need it for reference or inspiration.
Some personal favorites: The Joel Test of effective s/w development processes, painless software schedules, writing effective (read: convincing) functional specifications, and plenty of other gems.
My situation is slightly different from yours (24 yrs old and I was hired into the position instead of being promoted). Here's some of what I experienced.
;).
I do a lot more programming that I thought I would. It is an architect's job to visualize the project as a whole and come up with the best solutions possible. It is then necessary to express those solutions to everyone else involved. For coders, you can give all the presentations you want, but for them to truly understand it, they need code. I now spend a good deal of my time programming the "proof of concept" code. The size of the comments that I write is easily triple what I used to do as a developer (can't say that I was always good about commenting my code, but more often than not, I was). It takes a while to get used to creating code whose primary purpose is to be clear...not just to compile/run.
One of the other big adjustments that I had to make was the amount I had to deal with non-engineers. I deal with the people Marketing and Product Planning a lot. They look to me for acurate assesments of whether feature x is feasible and if it can be completed by date y. As an architect, they expect a much more "plain english" response from me than from someone in development. If I'm telling them news they don't want to hear (which is fairly often, since it is in their nature to think big), I need to give them an answer that they can understand well enough to report back to their superiors. This is harder than it sounds and has been a challenge for me (tho I think I'm getting better
It took a while to get used to all the extra meetings, but I now find my current position much more enjoyable than when I was in a development role. An architect role gives you the freedom to fulfill that urge to implement something as cleanly as possible (also known as the right way in the "right way v. fast way" debate).
An architect position is definitely the next logical step. Management is not the only end of this progression. Many companies have Product Planning departments or R&D departments. And believe it or not, you might get tired of coding...and if you do, it is nice to have the option of moving into a managerial position.
Hope you enjoy your new position!
"Don't blame me, I voted for Kodos!"
I'm making this thread more nested, because thats what I do on slashdot. ha, ha, ha. Thats right CmdrTaco, I'm still at it.
Ah, the irrational and instinctive belitting of a person who makes a valid point that you disagree with. I'd say you're ready for management.
This is a troll. Do you see the difference?
If you were blocking sigs, you wouldn't have to read this.
Hello good sir, here is my advice for you:
You should quit your job and become a wandering tambourine player. You could wander the country aimlessly, armed with only your trusty tambourine, a cup, and the shirt on your back. Ahh, that's the life.
I'm making this thread even more nested. You can't stop me, ha ha ha!
Several people have mentioned people skills and I would have to agree. The problem is where or how do you learn people skills? Specifically where do you learn the kinda people skills you would need for such a role.
In my previous role I had people skills in the sense of getting along with people famously, but not in the sense of being able to persuade other members of my team of the strength of my ideas (even though I arguably had the most relevant experience to the problems we were trying to solve).
Yes, the organisational structure contributed (I was in a team that comprised 3 people who were in different departments, on differnt floors who didn't talk to each other enough), but my lack of skills in this area was also an issue.
One of the other team members, by contrast, was a very good poltician, having the ability to steer people around to her ideas and her way of thinking easily.
Any ideas, advice on how to develop these kinds of people skills?
307 comments yet, but noone mentioned UML...
Architecture is definately the best tech job there is.
You get to play with all the new toys. (err.. Evaluate the latest technologies.)
You get taken to all the best restaraunts and bars by suppliers ( I mean establish fruitful working relationships with potential vendors).
Best of all you get to swan around, showing pretty slides with lots of boxes and look important.( ... comunicate new directions in technoligies to the companies descision makers.)
And if you can make as a Consultant Architect you pick up lots and lots of money, and, move on before somebody has to put your wierd and wonderful ideas into practice. (( .. constantly bring your in depth experience to new projects and customers.)
PS. I hope no one out there works out my real identity, or I may have to go back to doing a real job!
Old COBOL programmers never die. They just code in C.
Rewrote the removed functionality in approximately 4,000 lines of C and imbedded SQL.
The problem was that management allowed the code to reach such a state. But thats what happens when management only understands SLOCs
It's also what happens when good programmers are encouraged to only fix hot bugs and not allowed to re-factor bad but "working" code when they find it.
where there's fish, there's cats
Being your same age and in a similar role for 10-12 years, I'd say the following:
1) Since I've been doing this since I was in diapers, you'd better listen to me while I pontificate!
2) Since my number is TWICE as big as the asshole who wrote this post you better listen cause I am 2**2 times more (pick one) a) talented b) smart c)quick-witted d) generally nifty
3) Coding -- I know we all want you, but NEVER listen to your Mom's coding advice. Keep her spaghetti in the kitchen.
4) Make yourself noticeable by generally annoying behaviour like spouting off about your talent and decades of experience at every opportunity, flatulating when co-workers tell jokes, and picking your nose with your index finger during meetings.
5) Remember - you haven't changed. You're still the winy asshole who claims to have finished his PhD dissertation in the womb.
Is this because system architects are too busy to write web pages, or are unprepared to help other people up the ladder?
I think we should be told.
Or maybe I'll summarise this thread and post to the web...
Just A Programmer, not as young or enthusiastic about coding as he used to be...
Be Free: Free Software Tuition
I've seen the same track. Served in the coding trenches until I could build my big bag of clues. Started pulling out those clues when they'd have the most impact. Then went on to be the established 'guy who knows stuff'. Soon they had me sitting in on enterprise design meetings, wanting to know how changes to the sattelite system would impact branch operations, how we could make it all work together.
What I found is that once you move out of the trenches into that bigger role you had better keep lots of notes. Accountability is your only savior. You know how the coders all huddle together shoving pins into a little architecht doll? That's you baby. Unless you can at all times say why you made every decision, some day you're going to be in front of the inquisition. Those inquisitions in the break room with five irate coders hurt more than the ones in front of the boss's bench. The boss can take your pay. Your friends can kick you out of happy hour. Jobs are easy to find.
I spent my time as part of two large corporations with outstanding technology. I rose through the ranks and am about to start my tenth year in the business. I'm now a contractor who plays both rolls. Mostly now I'm the architecht, and if I'm not that officially, I usually end up doing some of that regardless. It's a big responsibility, much bigger than coding. You never want to be the reason five coders get to carry around the legacy of being part of the biggest laughing stock project in the firm.
- Sig this!
I'd call it insightful.
Maybe funny, but in a scary way.
Anonymous posts are filtered.
Is it me, or has the whole line of job titles kind of jumped up a notch? I think this happened sometime around when the "Architect" title came into constant use. Maybe it's a good thing, as the real Architect's are really calling themselves CTO's and getting that extra week of vacation.
Krispy Cream is people
Where's the money?
:-) then figure out how you're going to get more cash and do whatever you need to in order to get there.
If you want to get rich (you may not care, in which case ignore this
There is obviously a balance here between lifestyle, job satisfaction & cash (and only you know which balance will suit you best.)
My advice to you is to keep accepting promotions and more money until you get truly heartsick of your job. By then you will have had enough different roles so you know which one you liked best.
Then you can decide to either go and do what makes you happy, or go and do what makes you rich, depending on your personal goals & ambitions.
If you're lucky, they'll be the same thing.
Best of luck, whatever you choose,
Woobie
And there is everything else in between.
The BEST software developers are those who LOVE to write programs. They enjoy watching it come together, tracking down bugs, and especially watching someone use the final product to do something that they could never do before. They are there for the end-game on a project - when temper's flair and time is short. Also, they are lifetime learners...they study new programming languages and techniques long before the majority of their peers - and don't wait for their company to offically send them to training before cracking something open and finding out what makes it tick. The best developers are counted on to suggest a better way to implement something and never miss a chance to pick-up and improve their own approach when shown a better way.
The best architects that I've known are those who are dragged into the position after being top developers. A top developer will be acquiring the skills of an architect because this is how the concepts of design patterns, analysis patterns, data modelling, object modelling etc. are presented. Top software developers learn architectural principles because they realize at some point that allowing somone else to screw this up affects their work. Acquiring these skills allows them to review proposed "architecures" for flaws and "buildability."
My last remarks on this are to look in the paper and see how many jobs there are for software developers vs. architects. To be hired as an architect (as opposed to being "promoted" into the position internally) will require you to have significant education (MS in computer science - which you should have anyway) as well as significant software development experience and architecture experience.
And one last thing, on the interview, don't tell them that you got out of programming because you couldn't hack it anymore. Even if it's true, you should probably keep that to yourself.
I want to be alone with the sandwich
I'm in the same boat. I'm 27 and have a similar role on a development team, and don't want to go into management. (I'd fail, miserably.)
We've recently transitioned to XP. It allows me to fulfill an architect role while continuing to code. I can mentor and transfer skills to other developers without jumping into management. Since my manager recognizes my worth (especially when out sick or on vacation and the fires come) I don't have to move to an official architect position and deal with all the negatives the title brings. So long as you enjoy what you are doing and you are good at it, stay where you are. The recognition and the raises will come.
The worst thing to get rid of, though, is deployment. I have found that if you know how to deploy and keep a production system running, two things happen:
1) You are invaluable (especially when the fires creep up)
2) No one else wants to learn how to do it, so you are stuck being the biggest bus risk.
If you're so damn unhappy about your job, then leave. There are several thousand unemployed developers that would happily take your place.
Haven't you been reading the papers? Don't you know we're in a depression and have terrorists attacking us?
I suggest you get certified on at least 5 to 10 new design tools every year. If you can get your company to pay for your training - even better.
I want to be alone with the sandwich
Your not management, and you don't directly make management decisions. But every manager should get your advice at review time for any employee you have an opinion on. (and if you don't have one on someone that says something too, but what is never sure)
Make sure you are in charge. Marketing tells you what will sell, but you have to figgure out what can be done. Often you will know more than them, but still take their advice seriously if you can.
Be in charge. don't let micromanagers dictate stupid design decisions. Don't let programers make stupid mistakes. When someone is doing something wrong you need to step in and say "NO! that can't work". Don't be afraid to do it.
Know what everyone is doing. that goes with the above. Review everyone's code, at least part of it if the project is too big. You don't have time to test and debug it, but you should know something about it. (formal code reviews are important, but you don't need to be involed with them nessicarly, just know the code)
You have people on your team who have been writing code for 20 (!!) years and need to go to someone for coding tips?
Sorry for the troll, but this says much about the organization you work for (or maybe their hiring practices).
I am very small, utmostly microscopic.
Logical error. Criticizing others implies that the criticizer does not suffer from the specified faults. It's self-aggrandizement by implication.
I disagree. All good decision makers solicit input from others. It allows one to get inside other's heads and possible shed some light on something the decision maker missed. Although you may get 500 useless posts (relative to you), you may come across a gem of an idea. I think you are jumping to conclusions on the readers personal issues. The fact that they ask questions, instead of taking the "I know it all and your input doesn't count" approach, shows a good, if not great future decision maker. Leaders are grown/created/molded out of the ideas of others.
Honestly man, that fscking architecht knows 5h1t about anything, he does not know hot to make a concrete mix, he does not know how to make a straight wall, he has no idea about hot to put a door in place.
But he gets paid more.
I am telling you man, the work gets all done by the brick layers, it is like if those fscking architects just get license to retire pretending they know something when in reality they can't distinguish between a red brick and a lunch box.
IANAL but write like a drunk one.
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.
Coming from an architect's point of view, I believe that while it is important to undersatnd the logic inherent in the code, the actual nuts and bolts are necessary to keep up on because invariably there is someone there that has this knowlewdge. I believe I found my niche by understanding my product well enough that I can usually resolve even the most difficult help desk issue. If the issue is determined to be a bug, then use the specification (logic document programmers code by) to show the programmer right where to go to into the code. I believe an Architects primary roll is the interpretor between the Layperson and the Geek both of whom we have to make understand mostly using one written document. There' my 2 cents.
Just remember, without code, architects and managers are *totally useless* -- its really that simple :)
....
Translation: Yesssss. Bad managers, techies rule! The typical dotcom will conquer the world, Mars, the Universe...
Real life: Oh wait, dot bombs are long gone. Damn.
If you like working for small, agile companies and winning teams than XP is a great path.
Translation: Yesssss! This one explains the dot bombs failures! Agile, winning teams! God Bless America!
Real life: Er..., wait, those agile cheetas of the IT world are gone... damn.
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.
Translation: Oh yeah! I see the light now! Those monolithic bastards like MS, Oracle, CA, ha,ha,ha! The Fortune 500! Ha,ha,ha! Idiots. They are doomed! Ha,ha,ha.
XP rulez! Anyone too close minded to consider anything but XP is a close minded idiot.
I am not close minded, I use XP and nothing but XP over my dead cold body.
Real life: a teenie has not real life experience
---
I love a teenie deciphering the complexities of the IT world for the rest of us. Charming.
IANAL but write like a drunk one.
Let me see your resume first, then I will try to give you some hints on becoming a succesful software architect.
I find it hard to believe that a top notch coder would become a top notch architect. Why? because the different view angle of a coder and a architect.
A architect generally will look at the big picture whereas a coder will zoom into the details to actually solve some problems you won't see in the big picture. But maybe you are the exception to this rule. If so, learn as much as you can about time-management and communications skills because you will not be the first with a burnout at 38.
Since you are clearly arrogant and proud of your title. Let me tell you how the arrogance will destroy your career.
You will propose an architecture because you bought into the hype and mindshare coopted by marketing dollars and propagated by the mindless rabble of "me-toos" and wannabes. You won't have validated it because "how can so many people be wrong?"
The project will get to delivery and all those people with 20 more years of experience than you will hang you out to dry by saying that the performance problems are an architecture issue and they will point the finger at you. (This is why they have 20 years of experience and aren't the architect.)
As you sit in front of the COO trying to explain why it's the implementation and not the architecture, you will suddenly realize that consulting makes much more sense for your career.
As an old-timer with 30+ years experience I rather enjoy being current enough that 28 year olds ask *me* questions and seriously expect an answer. It is possible to stay up to date with technology and still work as an architect or a manager. It just requires that you spend a lot of time listening to the team members and a lot of time caring how the project and the people come out. If you do that, occasional fire-fights and crises will keep your technical skills up.
Eventually, becoming a manager may appeal to you as it finally did for me. Beware of stereotypes - they just limit what you can conceive of and ultimately what you can do.
...to sound so impressed with yourself. ive worked with a 28 year old architect who didnt know shit about shit, and didnt even know that, but assumed that because even bigger dipshits made him an architect, that we was. keep coding, and hope you are as good as you think you are or your ability to direct any of your developers wont be worth the card your title is printed on.
Translation: Yesssss. Bad managers, techies rule! The typical dotcom will conquer the world, Mars, the Universe... Real life: Oh wait, dot bombs are long gone. Damn.
:)
;)
....
Err... have you ever seen a successful project go into deployment with great managers and architects (per the Three Amigos that don't code), but no decent coders -- sorry can't be done, fool.
Also, 99.9% dot bombs were hardly agile or XP. I worked for a venture capital firm for more than a year and saw my share of these companies mostly fail due to shitty management and unrealistic goals.
Microsoft and Oracle were initially small agile startups, fool, so your argument SUCKS. Now, they mostly stay in business with their branding (business tactic, not technical) and in many cases unethical business practices, you flaming idiot
Translation: Yesssss! This one explains the dot bombs failures! Agile, winning teams! God Bless America!
Real life: Er..., wait, those agile cheetas of the IT world are gone... damn.
Translation: Oh yeah! I see the light now! Those monolithic bastards like MS, Oracle, CA, ha,ha,ha! The Fortune 500! Ha,ha,ha! Idiots. They are doomed! Ha,ha,ha.
See above, fool!
I have friends successfully using XP at MS, Oracle, Lockheed-Martin, the U.S. Army, and IBM -- so shut your trap fool!
XP rulez! Anyone too close minded to consider anything but XP is a close minded idiot.
I am not close minded, I use XP and nothing but XP over my dead cold body.
I use pieces of RUP, UML, FDD, SCRUM and other more agile best practices (which you haven't heard of I'm sure) where they make sense, fool. XP just happens to be the best place to start since it provides concrete practices and also acts as a litmus test to weed out bozos like yourself
Until you've tried XP or something like it which few learn over decades of work experience, you are a tech *teenie*, as you put it. Once you've seen the 12 practices in concert, you are mature enough to evolve to a higher stage of software development skills.
Real life: a teenie has not real life experience
I love a teenie deciphering the complexities of the IT world for the rest of us. Charming.
I don't see you providing any solutions, poor naive Mr. Fool. I agree with you on one point, God Bless America!
If you have the opportunity to go into management, take it. Don't screw around and whine about losing your coding skills. Remember this simple equivalence:
Coders are fired by managers.
Managers fire coders.
On what side of the equation would you rather be?
Who's unemployed now? Not the managers ...
I think you know you're not ready for the architect role but are being pushed into it by the company.
Better to remain lead/head developer.
I am not sure why developers/coders perceive architecture development as the natural transition from coding. In most cases that I am aware of, good developers make poor architects.
An architect is not necessarily a good coder. A good coder is, in almost all cases, not an architect.
Architecture development takes effective communications skills, excellent organizational skills, good business skills, and good management skills. If you are not seeking a management position, then architecture development is definately NOT for you. Arcjitects must be able to easily and transparently move between highly technical discussions and business/management discussions.
Just being a crack coder is not a qualification for being an architect. Many businesses are realizing this as the technology market allegedly contracts. Businesses no longer need to "put up with" techies in architecture positions. Businesses can be more selective and are overwhelmingly choosing business oriented technology workers over crack coders for architecture positions.
This is not meant to malign your skills. However, if you do not want to go into management, your career path is relatively limited -- probably senior developer is the tops in the current market (just two years ago, a top techie might be placed in a nice office and called CTO but this is becoming more rare).
In your expert opinion, what would you say to a female model who claimed it was a "closed" system??
In my 15 years, most architects I've encountered have usually fit into three categories:
Some folks are born with the knack to implement systems and as they progress, they hit tech lead positions that offer them a combination of implementation and architectural decision making responsibility. My guess is that the original poster likely fits this mold, though at 28 would not expect him to be seasoned.
My advice to him is to stay out of architecture until he get's more experience under his belt. The time will come when his path will become apparent. A previous poster suggested that he would know when the right position came to view. I agree wholeheartedly!!
If you're dead set on an architectural role, please keep this one idea in mind: "An architecture (or framework) cannot be made to fit everyone's problem space, and in trying to do so you not only alienate users/adopters/implementors, but likely will kill the whole effort over time by folks trying to make it fit." Sage advice from someone who has seen this happen on more than several occasions.
The time will also come for you to make the big managerial decision. My advice there is to stay true to yourself, assess your technical skills, and bail from a management opportunity if you still have implementation desires. There is nothing worse than a manager who likes to code or tell others how it should be done!! I disagree with those who say architects are necessarily on a management track. (The good ones aren't)
Actually, I know plenty of unemployed dotcom managers (and CxO's) from my VC stint in the Bay Area. The funny part is most of the managers gave up hope of finding a job several months ago and are now working at the mall or at the local fast food joint ;)
Even execs are hurting. The CEO of my last dotcom had to sell his $1.5million house and shiny new Lambo, the VP of Engineering had to defer his Corvette purchase, and our Linux loving CTO had to sell out and go work to Micro$oft -- no joke. I still have my $600k house and not so shiny Land Rover -- so much for the poor XP developer.
The only managers still employed are basically cleaning up the books and will probably be working at McDonalds before the end of the year.
I don't know any developer friends at viable companies that are getting laid off while management is spared long term. Most of the ones laid off took a bunch of managers with them or they were lame coders and never earned their paychecks. Only a handful of worthy (unlucky) devs got the axe to the long term benefit of their managers, historically a hollow victory for the soon to be burger-flipping pointy hairs.
Look most probably you'll never read this, but I like to make my points clear for posterity:
-You need both good managers and architects and techies. Most groups of only techies normaly fail miserably to deliver something profitable. To pretend otherwise is puerile.
-Monolithic monsters are monolithic monsters, ever if they began as "agile" companies (whatever that means). The reality is that most of those "agile" companies you praise so much are gone while the majority of thos "monolithic aberrations" you deride so much are all in business and going strong. After the dot bomb fiasco one would expect less infantile ascertions about "agile" companies. Can you care to describe your monolithic companies and give some names to illuminate our ignorance?
-You clearly deride anybody that does not use XP, like if XP was the holy grail of computing. Such an attitude is closed minded, puerile and not in tone with the suppossed experience you claim to have. if you have such experience then you should know by know that using half a dozen acronims does not replace real knowledge and experience delivering projects. There are plenty of people that don't use XP and that does not mean they are closed minded idiots in a monolithic environment.
I may be a fool, but at least I don't dare to make sweeping assumptions abouts Software Engineering like if the practices I follow were equivalent to exact science.
IANAL but write like a drunk one.
Sorry to get on a soapbox, but this seems as good a time as any.
I just hate it when people allow business jargon to supercede english grammar. You used the word "transitioned" as a present-tense subjective when it is clearly a past-tense verb. Another example of a common occurance of this is "We're going to task this paperwork to you." What you meant to say was "made the transition."
Why do we allow words like "synergy" and "proactivity" creep into our language? These are obscure words that motivational speakers and authors have decided to use to help you remember their "six sigma", "TQM" or "ISO 9000" plans for better business. At this rate, we'll all be talking like Bill Lumberghs in a few years, mm-kay? Great. What's happening?
Was that a Mix or a Wipe?Supermix?Or perhaps even a DVE move?
Look most probably you'll never read this, but I like to make my points clear for posterity:
;)
:)
/. poster some useful career advice. My statement, "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" is the only anti non-XP'er statement. It is merely a reflection of my experience over years of discussing XP with people and learning that the people working at these types of companies that "preferred" it that way generally are close minded, not just about XP but Java or the Web or whatever. If you happen to be working at such a company with your Dilbert shields on, and do it for the paycheck, your geek buds, or the 35-hour weeks than I'm not calling you an idiot. Might not hire you though :)
:)
I'll respond. It's fun. You are an easy target since you have a hard time keeping any of my comments in context. You would make a great reporter for the local scandal new hour
I'm just curious, have you ever even tried XP? If you have, what didn't work for you? If you haven't, then why bother responding to a topic you know nothing about?
You need both good managers and architects and techies. Most groups of only techies normaly fail miserably to deliver something profitable. To pretend otherwise is puerile.
That's why XP kicks butt, because it allows a group of top notch techies to deliver maximum business value. Sure you still need a customer that can communicate a business need, but you don't need traditional managers and "architects". If you meant good leaders (not managers) and coding craftsmen (not architects) than maybe we are in agreement.
SIDE NOTE: I'll take a mature craftsman coder (both personality- and skills- mature) who knows patterns any day over a UML-wielding poser brandishing a title from a totally inappropriate domain (i.e. construction). If you happen to accept an architect title so you could earn $150k instead of $110k (common sense), but continue to code then I've got nothing against you.
Monolithic monsters are monolithic monsters, ever if they began as "agile" companies (whatever that means). The reality is that most of those "agile" companies you praise so much are gone while the majority of thos "monolithic aberrations" you deride so much are all in business and going strong. After the dot bomb fiasco one would expect less infantile ascertions about "agile" companies. Can you care to describe your monolithic companies and give some names to illuminate our ignorance?
Maybe you should read one of the many good technical or business books on emergence or complex systems. They'll clear up that whole "agile" thing for you. Visa International (maybe you've heard of them?) is a great example of a company that succeeded based on these principles.
So when did I ever praise the dot bombs -- never!!! I saw into the innards of 50+ first hand as a software engineer, CTO, and associate partner at a West Coast VC. I would never classify these business failures as "agile" or "XP-like", just modern day tulips. A good majority of the Internet-related startups that I know of that are really using XP (with support from their *leadership*) are alive and kicking. A bunch of my former big-5 friends started a consulting firm a few years ago based on XP and were recently rated the fastest growing private company in my area!
As for monoliths, the list of failure far outstrips the successful ones, and the same applies for projects. Try naming 50 tech monoliths that have been around since 1990. It's common knowledge that Microsoft products ship 3 years late and take three major releases to stabilize (read: 10 years to a decent, stable product). Maybe my buddies spreading the XP word at M$ will change that
You clearly deride anybody that does not use XP, like if XP was the holy grail of computing. Such an attitude is closed minded, puerile and not in tone with the suppossed experience you claim to have. if you have such experience then you should know by know that using half a dozen acronims does not replace real knowledge and experience delivering projects. There are plenty of people that don't use XP and that does not mean they are closed minded idiots in a monolithic environment.
I never called anyone an idiot just because they weren't practicing XP. I was trying to give our poor
You're the one going around calling people idiots. Also, I never said XP is the holy grail -- just that it is a good starting place. Once you have grasped the 12 practices and their interrelations, then you can truly mature. Sure a handful get there on their own, but only after much pain and frustration (especially when teamwork is a must).
I may be a fool, but at least I don't dare to make sweeping assumptions abouts Software Engineering like if the practices I follow were equivalent to exact science.
Did I ever mention Software Engineering? Once again you're off putting words in my mouth. There is a huge difference between Software Engineering (huge DOD/NASA projects encompassing thousands of man years) and business software development (products with 1-200 developers) which is what most of us do. Many of us have "engineer" in our title, but aren't practicing real engineering anymore than "software architects" are practicing real architecture (a flawed paradigm to begin with). I have a former instructor at CMU (now with the SEI) who has documented how XP's practices are equivalent to CMM Level 3, and several friends using XP practices at CMM and ISO shops (more successfully than their TSP colleagues too).
I think you need to get out more and meet other smart devs. You might actually meet some XPers and open up. At this point I am done responding unless you show some capacity for original thought -- oh yeah, you're welcome for the education
I say a lot here but I mean it concisely and sincerely because I've dealt with this and felt this way before--
Get ready to start relearning yourself. My experience primarily as an architect tells me kids in the middle school range and higher (grades 6,7,8++) are the fastest learners and come up with the best new ideas in CS.
You must mentor and apprentice to loud-mouthed or reserved but very bright kids because you were once one yourself. You should do this even if your instinct is to fear, reject or deny teaching for whatever reasons. Perhaps someone or several people took time to teach you principles of coding when you were first starting out?
The apprenticing and mentoring is very important because young people shouldn't always have to relearn & reinvent ideas the older & more experienced pretty much know but instead incorporate their own ideas. There's doing something yourself and not telling others about it (prima donna) and there's working with others.
I guess you're working in a corporation and might be comfortable there but from my perspective corporations really don't care about any of the learning stuff because they're all about bottom-line profits right now--maybe they'll change their financial tables when they learn integrating support makes money in the long term, not costing it.
Your challenge (all of ours if we wish to get out of a bad recession) as I see it is to form something independent of a corporation, bypass them entirely because they're owned and operated by shareholders, not stakeholders of opensource.
In the medieval age blacksmiths, tailors and bakers had guilds and trained apprentices and journeymen. It can't be that different from today?!
Start a guild and draft an agreement with a corporation to get paid but don't enter into a contract with the corporation or let them proscribe the standards and practices of the guild because they're only interested in supply-side economics where you get very little. If you work on an opensource project you're a guildmember in some capacity demonstrating your craft.
"...not even 28..." Yeah, and I was happy to have my first group before I was 25. I had people older than my father working for me. Don't let that turn your head. I cannot tell you how many times I've heard someone brag about how young he was when he was made a manager. Happens all the time. You've been had, Buddy! You are getting promoted in a large part because you are cheaper than someone with 10 more years experience. Also, your lack of experience will make it easier for your management to manipulate you. I'm sure you walk on water at least once a week, but don't get carried away with vanity.