[lug] Career advice

[Rob Nagler]

On 1/2/10, Michael J. Hammel wrote:
> No.  I simply think underestimate yourself.

It seems we are talking past each other.  I run my own companies.
I have many people working for me.  Their job is to make it possible
for me to code.  When I code, I produce more for the company and
our customers than other people can.

>  You have a career.  It's just not "coder".  I read your other reply.
>  Whether you realize it or not, you're not just a coder.  You're a
>  problem solver.

I am a problem solver.  I solve problems by coding.  I sit down and
start writing tests and function in Perl.  That's coding.  That's what
I do.

When we get a new customer at bivio, they invariably want to sit
down and architect a system.  We have been forced into this situation,
and also invariably, we create something that's a lot more expensive
and less usable than if they just let us code.

Michael, I see your company does SBIRs.  Selling to the government
requires another level of indirection, which means "architecture" and
"proposals" and so forth.  That's nice and all, but it isn't actually creating
something useful for people.  SBIRs are rarely commercialized.  The
companies which specialize in SBIRs have good relations with the
government.  That's politics, not creating systems.

My consulting company's slogan is "Software that works".  That means
lots of things, but one of the meanings is that the software we build is
deployed or we consider the project a failure.  We have had a couple
of failures, but our hit rate is 90%, and lately, it has been 100%.  One
of the main reasons for the success is that we get an end-to-end
solution going very quickly, usually within three weeks.  This is then
put in use by the customer, and often times, their customers.  The
feedback we get solves a number of interesting problems in the
software business.  We learn quickly what we didn't understand.  Our
customer buys into the system very quickly.  Every time an end-user
suggests a fix or feature, we have an end-user for the life of the
products, because the system is partly theirs.

All the programmers at the company deal directly with end users.
Most of us do first tier support.  It's quite humbling and empowering.
Sometimes we can fix a bug and deploy it within 24 hours, and
it freaks out the end user.  I'm not talking about a hacked dev
process.  We always code, write tests, checkin, run the tests on
an test system, and then deploy to production.  And, I mean
always.   The rigor is extremely important.

I think some people in this thread are confusing "Architect" and
"Systems Engineer" with "smart person".  I believe that the only
way to build systems is with smart people.  Being smart does
not mean you "architect" anything.  You can sit down, like
Richard Stallman or Paul Graham or Jack Kerouac, and produce
something without having a clue about the overall structure of
your creation.  I think most great systems and art are created
that way (Rowling and Tolkien excepted :).

I have to say that most people who call themselves Architects
(even if they can code) are not code-enlightened(TM).  It's
sort of like people who think they are done when they can do
a headstand in yoga.  They don't understand the Zen of coding,
and probably they never will.  There's a reason they call it
"yoga practice".  We in the programming biz can't call it
"practice" or our customers would freak out.  However, there's
a difference in managing customer expectations and the best
way to build systems.  I think people who are Architects, confuse
the two, just like they think they fall into the Major Release
Syndrome(TM) trap.  There's no such thing as a release, there
is just a continuous flow of software, which gets "marked at one"
point as a release and then is followed by more software called
"patches".   Releases are for marketing purposes only.   Every
time you run "yum" or "yast" or whatever, you are simply turning
on the tap to let the software flow into your system.

In any event, you can't teach "code enlightment".  Just like you
can't teach people why tests are important.  I think the only way
you can get there is to work on the same exact system for a
decade or so, and then you'll get an idea of how little you knew
at the start, and how valuable the tests you wrote 10 years
ago are.

Rob