Fog Creek Software
Discussion Board




Joel Says:

"So for now, my advice is this: don't start a new project without at least one architect with several years of solid experience in the language, classes, APIs, and platforms you're building on. "

What advice (other than what Joel has mentioned) would you give someone (me) on who wants to be a Windows Architect?

Thanks,

Prakash S
Wednesday, December 11, 2002

Learn as much as you can on your own. Lie on your resume about your experience, and establish a network of friends who can serve as "references." Obtain "architect" position, work your ass off so that the project is successful. You are now an "architect," and will have real experience under your belt. Don't settle for less than a 15% increase in salary for each subsequent job hop. Save as much money as possible. Decide that being an "software architect" isn't a "real" career, and return to school to become a research scientist. Worked for me. ;-)

cagey
Wednesday, December 11, 2002

"So for now, my advice is this: don't start a new project without at least one architect with several years of solid experience in the language, classes, APIs, and platforms you're building on. "

What advice (other than what Joel has mentioned) would you give someone (me) on who wants to be a Windows Architect?

There might not be classes and APIs you are building on. It doesnt matter if you are a "Windows architect" or a "Whatever else arcitect", if you are not delivering what you are supposed to, people couldnt care less.

Patrik
Wednesday, December 11, 2002

>Lie on your resume about your experience, and establish
>a network of friends.

Either this is why I didnt like America or why I dont have any friends. YahhhHooo...Lets bomb Iraq.

Patrik
Wednesday, December 11, 2002

As a guess - write a lot of code.

I was reflecting on this the other day - work is in a bit of a pre-Christmas lull so I'm tidying up/refactoring some code and it's amazing how messy stuff I wrote less than 6 months ago seems.

The more code you write, the more different situations you have to deal with, the more insight you gain.

Right now I'm labelled as "architect" of the project I'm working on (but neither my job description or salary reflect this :) ) and it's something I'm sort of uncomfortable with - I know I'm not architect grade yet. I'd imagine I might be getting close in another 3-4 years.

Working with a good senior programmer/architect helps steer you in the right direction too.

Walter Rumsby
Wednesday, December 11, 2002

Walter,

"I know I'm not architect grade yet. I'd imagine I might be getting close in another 3-4 years."

What do you think cuts as architect grade? what kind of skills?

Prakash S
Wednesday, December 11, 2002

Hi Prakash S,

Care to point to the article/URL where you got this quote from Joel?

I am not sure what you mean by the term "Windows Architect".  Could you provide me with a loose definition so that I can better understand where you are trying to go with this.

While I take it the person using the nickname cagey
was trying to be funny there is a lot of truth in his post.  Why?  Ask ten people working in the IT industry what a "software architect" does for a living and you will get ten different answers.  People who posts on the comp.software-eng newsgroup argue about definitions such as "what is architecture all the time.  Heck, if the people doing the work can't agree on definitions, roles, responsibilites, etc. then how can we expect employers to understand there is a need for somebody who wants to call themselves a "Windows Architect" or a "Software Architect"?

one programmer's opinion
Wednesday, December 11, 2002

> What advice (other than what Joel has mentioned) would
> you give someone (me) on who wants to be a Windows
> Architect?

Maybe I'm a bit biased, but learning how Win32 is implemented on top of NT, what are the relationships between the two, what the differences, etc. can help you GREATLY

Primarily because NT is designed in a beautiful, consistent and relatively modern way that Win32 tends to hide and pervert, and because it teaches you how to interprete those obscure statements in Microsoft documentation

And what better source of information for a vastly undocumented environment than some raw source code?

Don't understand why did I say "biased"? Let me introduce the ReactOS project ( http://www.reactos.com/ ) for an open source Windows clone, of which I happen to be (have been) a developer. Ever wondered what happens under the hood of CreateFile? why those whacky paths beginning with two backslashes? just download our kernel32 sources, and read! http://mok.lvcm.com/cgi-bin/reactos/ros-cvs/reactos/lib/kernel32

Want to know how is PSAPI able to enumerate processes and their DLLs, and why enumerating processes doesn't require any privilege, while enumerating the DLLs of other users' processes requires the debugging privilege? (and what's the meaning of the debugging privilege, by the way?) Read the sources! (coincidentally, I have written ReactOS's PSAPI - and it's the only part of ReactOS that shows some coding discipline, IMHO :-P ) http://mok.lvcm.com/cgi-bin/reactos/ros-cvs/reactos/lib/psapi

Our current documentation is... well... non-existent, so some system calls (the functions beginning with Nt or Zw) may be a bit hard to understand by just reading the code, but there's an outstanding book on the topic by Gary Nebbet, "Windows 2000 Native API Reference"

KJK::Hyperion
Wednesday, December 11, 2002

Prakash,

As I've been reflecting over the code I've written I think I've written some pretty good sets of classes that can be used elsewhere with not too much fuss - I reused some of the code I wrote for my current project to provide a solution to help out our support department. So I think I can develop those kinds of solutions - maybe 10 or so class files with a discrete purpose.

I see architecture as being the skill to put together a number of those "sets" (ie. groups of 10 classes/functions) in a way that those sets work well together to provide a solution to a bigger problem. I'd probably throw in related topics like naming of files, locations of files, configurability, etc. which may seem small/insignificant, but can add time and affect how easily others can understand your solution.

In the case of my current project I don't think I've hit the nail on the head quite yet - my ideas and knowledge have evolved a bit (a lot!) since I began. Part of this is because there's a huge class library in Java and as my understanding grows I know better which classes to use when, I discover additionally libraries I can use (eg. I wrote a class to match XPaths on Strings of XML and then the next day discovered JXPath), etc - essentially the things Joel mentions in his article.

I'm a fairly curious chap, as I suspect you and most of the active posters to Joel on software are too. I try to read a lot of books, look at a lot of other code, etc. Given the amount of professional experience I have, I'd say I'll probably need just as much again (being just a dilligent, curious, etc) to get to the point where I would see myself as being capable of being an architect of medium scale solutions.

Walter Rumsby
Wednesday, December 11, 2002

Prakash,

I found the article that you are talking about.  I didn't see it until I refreshed my browser.

one programmer's opinion
Wednesday, December 11, 2002

I was trying to be sort of funny, but that was an actual description of my career. I

cagey
Wednesday, December 11, 2002

"The more code you write, the more different situations you have to deal with, the more insight you gain."

Although that in itself is true, I don't see how this gets you a level up.

Likewise, I don't see how watching a lot of television or movies brings me in a position to be a producer.

Likewise, I don't see how painting a lot of rooms brings me in a position to be an interior decorator.

Likewise, I don't see how laying a lot of bricks brings me in a position to be an architect.

The point is, different jobs require different skills, some of which you might aqcuire by watching or doing, but some of the crucial skills require education first and practice of those same skills later. Not just practice of related skills, but practice of the exact skills.

And to prevent going off on a tangent. Neither of the examples are meant to value one skill over the other.

Practical geezer
Thursday, December 12, 2002

Well sure, you gotta read books and the like and I certainly do my share of that, but lessons learnt from books only really sink in once you've incorporated them into your code.

Walter Rumsby
Thursday, December 12, 2002

True, but the point was that by writing lots of code you can somehow become a project leader, or architect.

Which is not true. It certainly helps, but the only thing it really contributes to is being an excellent coder, or programmer, or choose your term of preference.

With every level of organisation come different skills. You need to be aware of the properties of lower levels of organisation, but don't need to be an expert on that level too. That's the whole point of different levels of organisation. Otherwise we would never have gotten where we are today.

Practical geezer
Thursday, December 12, 2002

I think cagey has got it right.
Learn it by doing it. Just my two tax-free cents.

M.
Thursday, December 12, 2002

You learn by doing it, mostly what you are doing. Noone would argue that to become a better something, you should at least do a lot of something, provided you have proper guidance.

But doing a lot of something is not nearly enough to become qualified for something else.
Whatever the something and the something else.

Practical geezer
Thursday, December 12, 2002

I actually do think you need to write a lot of code to become a good architect. I hope I didn't imply that you can just be totally unskilled in anything and pretend to be an architect. (however, I have witnessed this firsthand) Geezer is right in that you are not going to be promoted into an architect position merely by writing a lot of code. YOU have to convince someone that you are an architect. I did this by just claiming that I was an architect (I had already written TONS of code in school, as a hobbyist, and at a job I worked through school) and having my references back me up. It worked out pretty well. This probably won't work if you are applying for an architecture position at Microsoft, but it probably WILL work most anywhere else. ;-) 

cagey
Thursday, December 12, 2002

thanks for your input guys!

Prakash S
Friday, December 13, 2002

"Geezer is right in that you are not going to be promoted into an architect position merely by writing a lot of code. YOU have to convince someone that you are an architect."

That's not actually what I meant. What I meant is that you have to acquire architect skills. Writing a lot of code might get you some, but by no means all. Simply tricking people into giving you the position of architect is not the answer either, although I can see how in some situations it might at least enable you to acquire the skills once you have the position.

I know plenty of good architects who never have written a line of code. But they have a good understanding of when detailed information is required to make architect-level decisions and when they do, they consult an accomplished coder.
So part of their strength is knowing when to get which information where, i.e. knowing what they don't know.
Now, would they be better architects if they had personal experience? I don't think so. At best they could save some time making decisions sometimes, but I doubt it because the time they spent recollecting and verifying, they don't spend on the remaining issues. And as you all well know, people are not very good at task switching, so the end result is that they're likely to be slower.
Now, of course there are exceptions, both positive and negative on both counts, so be sure that you take all the circumstance into considerations whenever you have to decide what applies to your situation.

Practical geezer
Friday, December 13, 2002

"Now, of course there are exceptions, both positive and negative on both counts, so be sure that you take all the circumstance into considerations whenever you have to decide what applies to your situation. "

Geezer, could you explain this?

Prakash S
Friday, December 13, 2002

I meant that most of what is discussed here is without context.

Some people have natural abilities to be a good architect but have only been coding so far. Others might have coded forever, and studied to be an architect, but lack the abilities to be one.

So realise that there are no absolute rules here, only probabilities and guidelines, as in life in general.

Was that what you wanted explained?

Practical geezer
Friday, December 13, 2002

Thanks for the info Geezer, that makes it a lot clearer.

- "What I meant is that you have to acquire architect skills."

What are the other ways of acquiring such skills, other than the one you had mentioned, which I have pasted below?

- "So part of their strength is knowing when to get which information where, i.e. knowing what they don't know."

Prakash S
Friday, December 13, 2002

I am not sure I understand your question, because you ask about ways of acquiring skills, but list a skill as an example.

For me aqcuiring skills at least involves education. That could be any of the following, or a combination:
- on the job training with proper guidance
- attending courses
- self study (trade magazines, literature, etc)

And then there is practice. Practice in itself won't get you the skills until you have at least some idea of what you are practicing. So you need at least one of the above to direct your practice. Practicing a related discipline might be very illuminating to understand some of the problems your discipline might cause other disciplines, but you at least have to understand the relation between those disciplines.

That is why I think coding a lot in itself does not make you an architect, but it can certainly help you appreciate the discipline more. But only if you understand the relation between coding and architecting, and that you do not get by coding alone.

Now, this applies to any discipline and its relation to other disciplines. Being a nurse does not make you a doctor, being a tester does not make you a coder, being a mechanic does not make you a driver, anyway, you get the point...

Now, did that answer the question, or was that the question? If not, reformulate and I'll be glad to try again :-)
Also, if you have good arguments to improve or correct my opinions, I am always willing to learn...

Practical geezer
Friday, December 13, 2002

*  Recent Topics

*  Fog Creek Home