How To Become A Software Engineer/Programmer
maximporges.blogspot.com
maximporges.blogspot.com
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
"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.
Besides that, this article is full of great advice.
"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.
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.
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.
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.
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).
Can someone clarify what he meant by this?
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.
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.
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.
Uh, not to be pedantic, but the title is "How to become a software engineer/programmer". He has already explicitly limited the scope of his post to technology, so in this context, "learning" does equate to "learning technology".