Coder or Architect? 405
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."
You're doing the right thing (Score:5, Insightful)
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
Re:You're doing the right thing (Score:3, Interesting)
I've worked at a company developing a quite-known operation system. I know about several components performing the same task, yet are duplicated. The OS in question is targetted at embedded system (in a way) which makes it even worse.
That's a good start for "code deletion"
Re:You're doing the right thing (Score:2)
Heh. Did this just last week with a project in serious trouble. A DB read was taking 25-30 seconds. I was called in, found a massive memory leak, and a way of dealing with the process that cut it by 10x in time, even before addressing the leak itself.
Re:Code Deletion Engineer (Score:2, Informative)
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.
Odd contradiction (Score:4, Insightful)
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.
Re:Odd contradiction (Score:3, Insightful)
This marked as a troll, but I have to agree with sentiment. People who are ready to be architects have generally worked on a variety of projects under some good architects and have some idea of the issues involved, such as coding standards, style standards documentation, organization, and other issues.
There is much more to a successful project than telling people what code to bang out, and unfortunately this is usually learned in the trenches. The dot-bombs are the ultimate example of what happens when you put people who aren't ready in charge of software projects.
Re:Odd contradiction (Score:2)
Unnecessary solutions to non-problems become problems in themselves that others have to deal with. A lot of software falls into that category. Such as Microsoft's Active Directory and other such nonsense. The only problem that solves is the lack of a monopoly on enterprise DNS services.
Re:Odd contradiction (Score:2)
I already know I'm satisfied with where I'm going. Having been an architect at the company for a year now, and quite successfully, based on project managers' feedback, I already know it's what I want to do. What I was looking for was input from others who have been there--who have made the same transition before. I can ignore the detritus from the "college students and other random posters," for the most part.
Re:Odd contradiction (Score:4, Offtopic)
There are a lot of people here with even more accumulated experience, and it is just that portion of the
It would be very interesting to see a
Re:Odd contradiction (Score:3, Funny)
It would be very interesting to see a /. poll asking the crowd how many years of experience they have.
All of the college students would lie.
Re:Odd contradiction (Score:2)
Some wouldn't have to.
There are tons of people here who have years of experience but have either just started college, or never finished. Some never went at all.
My suggestion, for what it's worth: Invest in a magic 8-Ball.
Rubbish. Ignore this foolish troll. (Score:5, Insightful)
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.
Re:Odd contradiction (Score:2, Insightful)
I would have to disagree completely with your comment. You have completely ignored one of the most important assets people have in decision making. Other people's opinions. Not that the're always helpfull opinions, but listening to others can serve you in many ways. At the very least he is open to the possibility that others may point out, or bring up, things he has forgotten or taken for granted. It is the bigger man who isn't afraid to ask others. It also shows he cares about the job he does, and is thinking about the future. I would much rather trust the future of one of my departments with someone who uses all resources at his disposal.
Let's face it, the issue are bringing up is more one of appearance than anything else. People appear less competent to subordinates if they are constantly asking others for advice. It is advisible to appear confidant and ready to the people he works with, however, you are taking it to the extream. You also don't sound very helpfull to people to people who are seeking guidance. A VERY important trait in anyone who is in a supervisory position over others. If we were to judge you based on the appearance you give us from your comment...
Whatever: Just get the job done. (Score:5, Insightful)
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.
Simple advice: Don't get swamped in meetings (Score:5, Informative)
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.
Re:So meetings are an Ego Magnet? (Score:2)
I'm sure that's true, but that ignores the ass-covering type of meeting. These tend to be held on a regular basis regardless of whether there's any need for them, and the fact that half a dozen or a dozen people are present serves to provide strength in numbers: something must be going on, because a dozen people are meeting every week about it.
The sort of managers who run this type of meeting can be the opposite of the kind of person who can put on a show: they're the kind who likes to keep their head down and not be noticed when something's gone wrong. When something does go wrong, they can point to how they've diligently been holding allegedly productive meetings, and the problem must lie elsewhere, preferably in another department represented at said meetings.
I currently attend one of these every Thursday at 9:00am, hence my intimate familiarity with the species...
Keep coding (Score:4, Insightful)
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.
Architect also implements (Score:5, Interesting)
Here's a hint (Score:3, Funny)
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.
Yes, but he's the essence of the /. user (Score:4, Flamebait)
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.
Re:Yes, but he's the essence of the /. user (Score:3, Insightful)
If we were all taught in school that we're just like everyone else and that no matter what you think, you're just plain old homo sapien, I think there would be a hell of a lot more depressed people around.
Or people wouldn't try at all.
The reason people put in all this effort is because they think they are different and can make a difference. It doesn't matter what the reality of it is. Are we better off knowing that we're plain, if that is indeed true? Where is your justification that we're not, other then a movie?
By saying that we aren't unique, you are yourself acting like some all-knowning being, who can see beyond our so-called social lie. Because of that you are making yourself sound exactly opposite to what you want to be perceived as -- you're being perceived as someone who thinks they know everything because they've seen a movie and understood one of the concepts within it that may or may not have been true.
Re:What makes you any different, Ars-Fartsica?[OT] (Score:2)
Logical error. Criticizing others implies that the criticizer does not suffer from the specified faults. It's self-aggrandizement by implication.
Re:Here's a hint (Score:1)
Re:Here's a hint (Score:2, Insightful)
If you're as good as you say you are you'll make 10X as much as working for any employer. If you're not, you'll come back a little older and a little wiser.
Keep coding... (Score:4, Insightful)
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
I have a suggestion... (Score:3, Funny)
Been there, done that (Score:4, Insightful)
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.
Easy! (Score:1, Troll)
And don't let yourself get sucked into project design/managemnet, which would defeat the purpose.
-Peter
Re:Easy! (Score:2)
However, project design is NOT management. It is very definitely a technical role, and should be something most senior programmers see as part of their job. Even one-(wo)man projects need some design effort.
Re:Easy! (Score:2)
But it doesn't answer the fucking question, does it?
-Peter
PS: Get a fucking login, twit.
-P
That's another issue Extreme Programming solves! (Score:3, Informative)
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.
Re:That's another issue Extreme Programming solves (Score:1)
We regret to inform you... (Score:5, Insightful)
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...
Advice (Score:5, Interesting)
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!
Re:Advice (Score:1)
My job nowadays is as much marketing/product management as it is engineering
So you do marketing work?
I can do more good for the company as a whole architecting solutions in the holistic space rather than as a disjoint entity.
Evidently so!
Re:The Mythical Man Month (Score:1)
with a decent compsci selection...
hmm, a few random thoughts.. (Score:5, Interesting)
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.
The summary : wisdom is key (Score:2)
Speaking from my own experience. (Score:1, Troll)
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.
The fallacy of this story (Score:5, Insightful)
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).
Re:The fallacy of this story (Score:2, Insightful)
Free-lance consulting (Score:5, Informative)
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.
But how do you start? (Score:2)
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. :-)
What a great combination! (Score:2, Funny)
Huh?
A *SOFTWARE* architect?
Oh. Never mind.
Re:What a great combination! (Score:3, Informative)
Position vs Role (Score:5, Interesting)
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
Be flexible but go with your strengths (Score:4, Interesting)
You should check out Norm Matloff's Debunking the Myth of a Software Labor Shortage [ucdavis.edu]. In a few more years, you probably will want to transition into a lead design or managerial role, so this track is reasonable (especially if you want to become say CTO of some firm during the next upswing in the tech sector).
There have been several remarks say that you should continue to code. It is probably not a bad idea to continue coding, however, being a good leader/manager DOES NOT mean that you need to be a great coder. It helps to win the engineer's respect, but if you follow sports, you know that the best coaches were not necessarily great athletes in the sports they coach (e.g. Bela Karolyi in Women's Gymnastics) but they do have to understand both their people and the jobs that they do.
The most important thing is to ride out this current weakness in the economy and position yourself for a profitable and successful ride in the upswing. Don't get trapped into obscure or uninteresting technologies by chasing short term rewards.
Re:Be flexible but go with your strengths (Score:3, Interesting)
Actually, you shouldn't. The rapid increase of salaries since the report first came out (1998) pretty much invalidates any claims made by Norm.
How to be a good 2X-yr old architect (Score:2, Insightful)
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.
Watch your back. (Score:2, Insightful)
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.
How to keep your hand in coding? Wait for crises. (Score:4, Interesting)
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
Re:How to keep your hand in coding? Wait for crise (Score:2)
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.
THIS is what makes opensource work (Score:1)
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 would've said "I'm an architect". (Score:1)
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...
Keep a hand in (Score:2)
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.
Architecture vs engineering (Score:4, Informative)
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
Architect is a temporary role (Score:4, Insightful)
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.
Can I come work for you? (Score:5, Funny)
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?
success? (Score:1, Interesting)
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
Architect or Engineer? (Score:1)
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.
Architect == My Shit Don't Stink (Score:5, Insightful)
An alternative career path suggestion ... (Score:2, Funny)
Architects need to be wide as well as deep (Score:5, Informative)
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?
Most programmers have to be architects (Score:2, Insightful)
How to be a successful Information Architect (Score:5, Insightful)
1. Clearly define yearly goals. Make sure they're realistic and qualitative, not quantitative. Include in your goals learning something you are interested in. Have your manager sign off on them.
2. Touch every project you know of that's related to your work. No need to get heavily involved. Look at the project, know what's going on, know the technology, know how it will affect your work. Write an opinion, recommendation, or just a report. Make it short and high-content. A pretty picture never hurts. Make sure to email it to PHB, as he probably won't remember to look at your intranet site. At least then his sec2 will have read it. Do this at least once mid-way through each quarter.
3. Write quarterly reports. Trump up any work you've done on popular projects, keep work on politically sensitive projects to a few lines. Again, email to PHB. This time he'll read it. They always read quarterly reports.
4. Request at least two weeks of training a year. Make these requests at least two months before you want to go, or within ten minutes of hearing your boss mention extra budget money. Include summaries of what you learned at these training sessions in your quarterly reports.
5. Request to go to at least two conferences per year. Again, write about what you learned at these conferences. Include in reports.
6. Write a yearly report and hand it over in November, along with next year's goals. Make sure your yearly report shows that you met or exceeded each of your goals.
7. Don't piss too many people off.
-----------------
So that's it. Do this and you'll be an information architect for as long as it amuses you. I'm serious.
Now if you need some ideas on training and seminars, and the general work part of being an information architect, just go here: Object Management Group [omg.org] - you should be able to take care of the rest here.
Good luck.
Re:How to be a successful Information Architect (Score:2)
I'll translate a few of these, for those who haven't learned to read before the lines.
"It's harder to lie about whether you met a goal when it has numbers attached to it."
"Drive everyone crazy by constantly pestering people for information and/or making useless suggestions based on superficial understanding of the real problems. Come review time, you can claim you helped everyone, and the damage you've inflicted on their schedules will make you look good by comparison."
"Take credit, avoid blame."
"Spend as much time as possible away from the office so that the people doing real work can't hunt you down and give you that well-deserved kick in the teeth."
"I have a financial arrangement with these guys."
Have a care... (Score:2, Informative)
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.
Life Plans (Score:2, Insightful)
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
I believe BNL said it best... (Score:2)
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.
Support, Develop, Architect (Score:5, Insightful)
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.
The question is not whether you re done coding (Score:5, Interesting)
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.
Re:The question is not whether you re done coding (Score:3, Insightful)
Bzzt! Few people have ability to make themselves irreplaceable
You don't 'make' yourself irreplaceable. Either you are or you are not.
I once worked with a government agency where much of the work was done by consultants. The consultant's idea of making themselves irreplaceable was to take all the comments out of my configuration files to make sure that anyone else would have great difficulty getting the machines to work.
Target is to make people replaceable and places easy to work. Make projects fasttrack, and be there on date, and be quality dependent. Reduce stress levels, and put project support on people strongest points, not weakest - XP.
That sounds like the type of bubblehead speak worthy of the pointy haired one. What the heck does that utter drivel mean?
Why not leverge a few underlying synergies and look for opportunities to upwardly impact positive attributes while we are at it?
I don't see any reason to believe that the current fad for 'Extreeme Programming' is any more substantial than those that preceeded it. It shows all the signs of being a management fad, it panders to the egos of those promoting it pretending that they are some sort of elite while peddling a small number (between 5 and 7 is usual) of plattitudes that are dubbed 'core truths'. Near as I can make out all XP boils down to is 'a small number of true experts are better than severl hundred also rans'.
Unique people often are hightly opinionated, get in way of actually doing things. After all that company does not benefit from them.
Again what the heck does that mean? Most people are unique.
What does 'opinionated' mean? That I value my opinion over those of other people? Pretty hard to be an original thinker if you always defer to conventional thinking.
If you want to make a significant impact in a field you have to be confident enough in yourself to take on the opinionated buggers who have already established themselves. That will make you 'opinionated' in the minds of the people who think you are wrong.
Re:The question is not whether you re done coding (Score:2)
I hate it when people say things like this without explanation. My personal experience is that the more experience you have, the better a programmer are you. You'll be better at 40 than 25. But the reason why "older" programmers do less coding is that they start to see just how crappy most programming is. You have to use C++ instead of slicker languages. You have to work crunch time that wouldn't be allowed if you ran a machine in a factory. You find that most projects get done simply because there are a dozen 22 year olds, fresh out of college and living in a new town where they don't know anyone outside the office, working 16 hour days because they have nothing better to do.
Re:Huh??? Over the hill and can't code at 30??? (Score:2)
In a commercial environment, if you want to avoid that, you pretty much have to move up the ladder, which is ultimately going to mean team lead, project lead, architect, mentor, consultant, or something along those lines. If, however, you program for fun, none of this really applies.
I feel that at 28 my skills are better than they've ever been
Assuming you don't let yourself stagnate, you'll feel the same way at 38, and probably even at 48, as long as you don't suffer from any degenerative brain diseases. But observing some of my colleagues and even myself, stagnation is all too easy as time goes by. It's tempting to think that you know everything you need to know.
You have to challenge yourself. Don't just read the magazines and books you find in bookstores (you know, Dr. Dobbs and Teach Yourself Java in 21 Days), get hold of and work through some of the books that are famous in academic circles (e.g. SICP [mit.edu], to name just one obvious one), subscribe to some ACM journals, learn new languages, take some advanced courses. Take on projects that challenge you, that you don't understand how to do. Learn what you need to learn to do them. (Don't necessarily do this for projects that your career depends on, though!)
Not only will this be personally satisfying, but it'll make you more marketable, too.
A few warnings from someone who's been there.. (Score:2, Insightful)
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
Just do what you love to do (Score:2, Insightful)
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
Start your own company. (Score:3, Insightful)
Architecture is a big word (Score:2, Insightful)
Who is right for the architect role? (Score:2, Interesting)
"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.
The Anusflange real question: (Score:2, Funny)
Don't forget (yuck) process and (yes) giveback (Score:2, Insightful)
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/ [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.
Possibly unpopular opinion, but here goes (Score:5, Insightful)
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.
Re:Possibly unpopular opinion, but here goes (Score:2, Interesting)
Architect as Gardening (Score:2)
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.
Re:Possibly unpopular opinion, but here goes (Score:2)
My manager, however, will simply ask questions. He'll give you just enough rope to hang yourself. Once he's asked enough questions, everyone will see his perspective and sometimes even act upon it. Given the choice between his approach and mine, I'd take his any day. Unfortunately, I lack the ability to subtly play dumb.
Not all management is worthless. Believe me, I've had my share of bad managers. The good ones, from the developer's perspective, leave the developers to develop and shield them from the corporate BS while doing it. In all my outward facing responsibilities, that's what I've tried to do. The less they need concern themselves with the politically correct answer and more with the technologically correct one, the better for all involved.
Listen to Joel! (It's painless.) (Score:2, Funny)
Joel Spolsky, another engineer-turned-architect writes thoughtful, entertaining, straightforward essays [joelonsoftware.com] 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 [plkr.org] 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 [joelonsoftware.com] of effective s/w development processes, painless software schedules [joelonsoftware.com], writing effective (read: convincing) functional specifications [joelonsoftware.com], and plenty of other gems [joelonsoftware.com].
UML tools? (Score:2, Informative)
Job Titles (Score:2)
Be in charge. (Score:2)
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)
Making the Transition (Score:3, Interesting)
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.
Re:Special Projects Coordinator (Score:3, Insightful)
This is not a slur against you or your skills, and that company could have used entirely different naming conventions, but I found it quite surprising that that term was used in two different contexts within a few days of each other on
Re:Special Projects Coordinator (Score:2, Interesting)
Special Projects
Special Education
Special Forces
Special Prosecuter
Special Interests
Special Olympics
Special Effects
Special Weapons and Tactics
It's not *always* perjorative...that depends mostly on how you felt about the ordinary, "unspecial" stuff.
"Isn't *that* special!" --The Church Lady
Re:Translated this post reads. (Score:2, Funny)
Re:Translated this post reads. (Score:1)
Re:Translated this post reads. (Score:3, Interesting)
"I am a whining loser that can't find a job and I am going to bitch about it on
Then they will sit there and think to themselves, "I just wasted +1 on this fool."
Honestly, I am happy for the guy and I could see him seriously asking this question only for feedback from the largest group of online people in his field.
Go back and cry to yourself, not to us.
Re:Translated this post reads. (Score:1)
The original poster is asking for advice and whatever ulterior motive he may have there is no call to be rude. Slashdot as a forum would be much improved without baseless accusations and jealousy being moderated up.
In finishing, I'd like to make an observation: if the individual in question was as egotistical as you claim, he would probably have linked to his homepage or a CV (resume), but he didn't.
--
Re:Translated this post reads. (Score:3)
This is great. I think I'm going to post it in my cubicle.
Seriously though, you know nothing about what I've done with my life/career. For all you know, I may have been freelancing since I was 12 (I have), I may have been working in IT since I was 16 (I have), and I may have been developing since I was 14 (again, I have). I don't claim to have the most knowledge (I don't), and I don't claim to have the most experience (again, I don't), but I do have the ability to see both the forest and the trees at the same time, which from my experience is pretty damn unique in the field.
Re:Translated this post reads. (Score:2)
Look... (Score:2)
And if it doesn't play well here, it isn't going to go down any better at work...
Re:a question for the young genius. (Score:4, Funny)
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.