How To Become A Software Engineer/Programmer

http://maximporges.blogspot.com/2009/06/how-to-become-software.html

by benatkin • 17 years ago

59 34 17 years ago

maximporges.blogspot.com

dmix• 17 years ago

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?

johnnybgoode• 17 years ago

Maybe he meant you should always be willing to replace your code, either with your new code or someone else's.

tdavis2• 17 years ago

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• 17 years ago

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.

andreyf• 17 years ago

This has nothing to do with code, really - in any profession, people get emotionally attached to their work, and are unable to have a discussion without making it personal. What he means is that you should be able to discuss your technical decisions (code and otherwise) without feeling personally criticized/defensive.

timwiseman2• 17 years ago

In other places I have worked, this is referred to as "having thick skin". Essentially, you need to be able to accept criticism of your code when it is valid and be willing and ready to change it.

benatkin3• 17 years ago

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• 17 years ago

Can you please explain the difference?

branden• 17 years ago

They're ways to solve two different problems. The goal of application development is to make a user happy (for some value of happy), and the goal of software engineering is make a good system (for some value of good).

benatkin3• 17 years ago

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.

stevejohnson• 17 years ago

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.

Confusion3• 17 years ago

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• 17 years ago

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

ideamonk• 17 years ago

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.

benatkin3• 17 years ago

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

maximporges4• 17 years ago

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• 17 years ago

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.

maximporges4• 17 years ago

I think I did say that... :)

davidmathers• 17 years ago

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

Confusion3• 17 years ago

Unless these numbers are from a crystal ball and apply to circa 2015, it proves nothing about the relevance of Ruby skills a decade from now.

TheSOB88• 17 years ago

He's comparing old languages to a modern language.

timwiseman2• 17 years ago

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• 17 years ago

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

edw519• 17 years ago

"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• 17 years ago

"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.

donaq• 17 years ago

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.

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".

How To Become A Software Engineer/Programmer

Related Stories