Re: [tlug] [OT] Good IT Resume

["Josh Glover" <jmglov@example.com>]

On 01/08/07, Curt Sampson <cjs@example.com> wrote:

> Sure. But this is why large companies have smaller companies develop a
> lot of the good stuff, and just buy them later. They often just can't do
> it themselves due to their own politics.

What about large companies like Amazon and Google that manage to get
things done whilst being big?

Sorry, but your argument about politics is basically Ivory Tower
bullshit; *you* can choose to start your own company and "never" have
to deal with "politics" (but what about political fallout inside a
company you are consulting for?), but people who are working at large
companies that are *not* completely broken still manage to get a lot
of good work done. Part of that is knowing how to deal with the
politics and the policies. I consider that one of my most valuable
skills as an engineer: I can get stuff done even when sometimes it
seems like no-one wants me to succeed. [1]

> > I am an engineer, and I don't want to read your code before reading
> > some prose that tells me what problem you solved and how you did it,
> > roughly.
>
> And you think of that as a spec, and would be happy to implement from,
> "how I did it, roughly?"

Curt, please re-parse my above sentence before foaming at the mouth.

I think I bring out the argumentative in you or something. :)

What I said was that I don't want to read your code *before* I read
some prose etc. etc. Reading the prose allows me to have an idea of
what your code does before I get into it, thus allowing me to read it
faster and with a better idea of what is going on overall.

Obviously, I would not re-implement your code from scratch.

But the point is, I can and do implement code from a spec, and
strangely enough, my projects succeed. So your line that the only true
spec is an executable one is not actually true in reality, any more
than "thou must have a paper spec to succeedeth" is true (which is
never something I have said in this thread; my contention is that a
paper spec always adds value, but usually will not make or break a
project... at least until you have to come back to it months or years
after initially writing it).

> > Reading code is hard....
>
> Here's my whole point: it doesn't have to be. If reading the code is
> difficult, fix the code.

I agree with you, and I write clean, well-designed, and correctly
commented code just so the maintenance will be easy.

But still, English and diagrams (if a picture is worth 1,000 words,
it's got to be worth 500-2,000 lines of code, depending on how you
think code fares vs. English) are much easier to read than code,
especially when there are not so many words and diagrams, and there is
a lot of code.

Cheers,
Josh

[1] Which is a blessedly rare thing at Amazon, but at my last job, I
almost always felt like that. The only evidence of people wanting me
to succeed was them telling me I had to launch in a month; never mind
that they would not give me the tools, people, or working environment
to do that. Oddly enough, I don't work there any more... ;)