

How To Become A Software Engineer/Programmer - benatkin
http://maximporges.blogspot.com/2009/06/how-to-become-software.html

======
davidmathers
_the skills you learn today will be irrelevant in less than a decade_

O RLY?

<http://www.indeed.com/q-fortran-jobs.html> \- Jobs 1 to 10 of 1,231

<http://www.indeed.com/q-cobol-jobs.html> \- Jobs 1 to 10 of 3,022

<http://www.indeed.com/q-ruby-jobs.html> \- Jobs 1 to 10 of 4,208

~~~
timwiseman
You have a very good point, and I slightly disagree with that statement in the
blog post. But I think the core point he was trying to make has some validity.
Perhaps it could be more accurately (if less succinctly) said:

"The specific technologies you learn today will either fade into obscurity or
else evolve dramatically. To remain at the high end, you must continue to
either follow those evolutions, learn the newer technologies, or preferably
both."

For instance, I am not a FORTRAN or ruby expert, but I understand they have
both evolved enormously since their initial release and someone who has not
kept up will at least be at a disadvantage. I do follow MS SQL Server closely
and someone who learned on say MS SQL Server 6.5 would miss out on a lot of
advantages of MS SQL Server 2008 if they had not made the effort to keep up
with the evolutions in between.

As a side note, I knew a lady like that. She was a nice person, but she
learned SQL Server 6.5 just to get a job and did not keep up with the changes.
A lot of the code she wrote had to be run in compatibility mode and of course
she missed out on newer features that would have made her code faster and
easier to read simultaneously. She ended up getting laid off.

As for Cobol, correct me if I am wrong, but very little new development is
done there, it is mostly maintenance coding and small upgrades for very old
systems. Even if it paid the bills, I would not want to wind up as that guy
maintaining ancient code that was simply too entrenched to be replaced yet
personally.

~~~
Retric
Some of those Cobal people bill 500$ an hour which is worth putting up with a
lot of pain IMO.

------
stevejohnson
I don't like the way he trotted out the old "C++ will always beat Java/C# in
speed" line. It ain't necessarily so.

Besides that, this article is full of great advice.

~~~
Confusion
It's not very smart of him to do that, because you can bet half the
discussions about the article will focus on it and completely miss the point.

~~~
eru
And anyway, C is faster. Or Assembly. So it's not even worth to sacrifice half
of the discussion he generates.

------
benatkin
The part I would most have liked to have seen earlier in my career is this:

"Early on, decide if you want to focus on application development or software
engineering."

I've heard this in many other ways, but this makes it simple enough for me to
understand. Other times, it's been three or more categories or with less clear
terms. I think this is about as simple as it can get while still being a
useful distinction.

~~~
quizbiz
Can you please explain the difference?

~~~
benatkin
I'll try.

The application developer is most interested in designing user interfaces.
They tend to have lots of ideas for new apps and new features. They want to
impress people with new stuff.

The software engineer wants to fully understand domains and be able to solve
just about any given technical problem. They want to be trusted by people to
perform in the most challenging of situations.

After better understanding the distinction, I have more respect for people who
call themselves Software Engineers, and can back it up -- people who can fix a
messy database, perform security audits, bring up a system that went down, or
create a complex system. I also wish I had a really good software engineer
where I work so I could focus on application development, and not on improving
database performance, which I can do, but isn't my passion.

~~~
maximporges
Hmm... not quite what I was going for, but close. There's been the most debate
on this particular point in the various places my blog entry has ended up
being posted, so I'll try to clarify it here too.

In the simplest terms: my experience has been that when you specialize in app
dev, you deal primarily with databases, service architecture, UI toolkits, web
services, etc. You generally rely on an app server environment of some kind,
work with/rely on a lot of tools from vendors and the open source community,
etc. This is where I have specialized in my career, and what my software team
does.

There's another team where I work that builds tools and processes that mainly
run on a large farm of servers. They are all high-performance, high-throughput
data delivery and media transcoding programs. These guys are absolute C++
wizards, but their software never sees the light of day and they almost never
use anything off-the-shelf, be it databases (don't scale high enough) or
third-party libraries (too much mistrust of potential performance issues).
There are a few C++ standard libs that they use, but not much else. These guys
are specialized in making really small, light programs from scratch that will
run headlessly on a server.

I've noticed a radical difference in approach between our two teams. There are
generic areas of crossover, such as our mutual understanding of good OO design
and suchlike, but that's about it. The other team would be as lost building a
client-facing app with a UI in front of it and a DB behind it as I would be
writing a high-performance server-side app from scratch without the flurry of
off-the-shelf libraries I've become so accustomed to.

In retrospect, I think "software engineer" was a misleading and incorrect
title for this skill set that the other team I work with has, but I'm still
not sure what would be more appropriate - perhaps "systems programmer"?
Anyway, hope this clears up my perspective.

Obviously, there will be 1000 shades between specializations, but generally I
would say somebody getting in to the field would want to head toward one camp
or the other as they get started.

------
ideamonk
I wish I could also become a "Rockstar" or a "comedian" or something else
reading things titled "How To Become A ..."

Hmm, can't see the word "open" written there, doing/contributing to open
source projects would definitely give a person, true feel of what if feels
like writing software in large groups of people.

~~~
benatkin
Given that there's at least two links to Flex websites on the blog, that's not
surprising.

~~~
maximporges
That's a good point; getting in to the popular open source libraries is
definitely a good thing for somebody to do, whether for reference or as a
contributor.

I'm actually writing an open source library for Flex (although I have not
publicly released the source yet - it's pre-alpha and being reviewed by some
peers).

<http://code.google.com/p/loom-as3/>

------
agocke
I'm not sure why this never gets said, but a degree in computer science helps.
No, its not always required and a lot of people in unrelated fields have ended
up going into software engineering, but we might was well be upfront and
honest about what a lot of people would like to see for a first time employee.

~~~
maximporges
I think I did say that... :)

------
dmix
The author wrote about not being emotionally attached to your code as being
one of the top two qualities but doesn't mention it again.

Can someone clarify what he meant by this?

~~~
tdavis
Basically, you should be able to take constructive criticism and not defend
your work based on anything other than objective correctness. You shouldn't
get upset with someone who says "your code sucks," you should ask them "why?"

~~~
decode
This seems like a good trait to have, no matter what job you're doing. Whether
you're a manager, a construction worker, or a software developer, criticism
should be seen as a chance for learning and improving, not a personal affront
to your pride. But, I can definitely see that this quality may be especially
important in software development because code reviews and design reviews are
so commonplace and frequent.

~~~
bmj
I wish it were more commonplace. I've been in the industry for ten years, and
my current employer of two years has been the only shop where there are
scheduled code reviews. I think it's great, and I enjoy reviewing other
people's code as well.

~~~
Nekojoe
That's one of things I like about my job. Every line of code has to be
reviewed by another developer.

It can't be checked into source control until it's been reviewed.

There are lots of benefits:

We all have to write readable code.

We can't just put in hacks.

You learn stuff. When reviewing others code you can ask why they did something
in a certain way. Sometimes you'll learn about the benefit of coding in a
certain way, or using a certain method / style / whatever.

This also has the benefit of redundancy. It means at least two developers know
an area of the codebase. So if they're away there are no bottle necks, the
other developer can also code that area.

------
edw519
"There is no right answer ... and always a better way."

I prefer, "There are many right answers, some better than others."

"Show and discuss your code, without emotional attachment."

Not my experience. I have always had emotional attachment to my code. My love
for my code is what has enabled me to grow. Passion is half the battle.

"People who learn one hot language just to get a job mostly find themselves
ten or more years later as one-trick ponies on outdated software platforms."

If a programmer has delivered 100 great projects with the only language he
knows, does that make him a "one-trick pony". Just because there is a new
favorite language du jour doesn't mean that all other software ceases to
exist. There are plenty of COBOL and BASIC programmers still doing very well.

"Since they have no real interest in learning anything else,"

Since when does "not learning more languages" = "not learning anything else"?
I know plenty of people who have used basically the same technology for 20
years and have learned plenty of others things. OP discounts domain knowledge,
deep industry knowledge, and business saavy. Believe me, you can solve _lots_
of diverse real world problems with a very small technology footprint.

OP's advice scares me a little bit because he equates "learning" with
"learning technology". If you're not careful, the next thing you know, you
will have learned a lot but insulated yourself into an ivory tower.

I prefer much simpler advice. Keep finding customers (internal or external)
and help them solve their problems. Lifelong learning will be a byproduct that
will take care of itself.

~~~
imp
"Show and discuss your code, without emotional attachment."

Not my experience. I have always had emotional attachment to my code. My love
for my code is what has enabled me to grow. Passion is half the battle.

I got the impression that he meant that it's easier to receive constructive
feedback when you're less attached. Not every line of your code is perfect, so
if you're able to stand back a bit from your code then you'll be more open to
improvements. It's something I still have trouble with sometimes, but I
usually try to be less attached to my code.

