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."
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
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.
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.
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
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?
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
Actually, a software architect is to a software engineer as a building architect is to a building engineer. An engineer can design a building easily enough, but it won't necessarily look pretty. An architect specializes in studying entire solutions, applying known formulae to new projects (such as a split-level-ranch style home design for your lot). The architect will mostly use components and designs that are already available, but must be skilled enough in engineering to fill in the blanks and make sure everything will work properly together. This is analogous to what a software architect does, which is to supervise the overall design of the software, making sure it is both solid and appealing to the end user.
307 comments yet, but noone mentioned UML...
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