How To Become A Software Engineer/Programmer(maximporges.blogspot.com)
maximporges.blogspot.com
How To Become A Software Engineer/Programmer
http://maximporges.blogspot.com/2009/06/how-to-become-software.html
7 comments
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.
"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.
Some of those Cobal people bill 500$ an hour which is worth putting up with a lot of pain IMO.
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.
Besides that, this article is full of great advice.
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.
"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.
Can you please explain the difference?
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.
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.
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.
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.
[deleted]
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).
Hmm never thought of it that way. So being an application developer has a more direct tangible effect on the end user as compared to being a software engineer. By that definition then most startups are built by application developers. I guess I know where I'll be specializing in from now on.
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.
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.
Given that there's at least two links to Flex websites on the blog, that's not surprising.
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/
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/
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.
I think I did say that... :)
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?
Can someone clarify what he meant by this?
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.
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?"
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.
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.
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.
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.
[deleted]
[deleted]
My thoughts exactly.
Maybe he meant you should always be willing to replace your code, either with your new code or someone else's.
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.
"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.
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.
"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.
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.
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".
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".
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