I regularly receive requests for career advice, and I've tried to capture the answers in this blog, and in a follow-on. For those of you who asked but never got an answer, I apologize. Your questions stimulated me to work on this, and it's taken awhile.
The question that people ask is usually the wrong one: "should I learn C++ or Java?" In this essay, I shall try to lay out my view of the true issues involved in choosing a career in computing.
Note that I am not talking here to the people who already know it is their calling. You're going to do it regardless of what anyone says, because it's in your blood and you can't get away from it. You know the answer already: C++ AND Java AND shell scripting AND Python AND a host of other languages and technologies that you'll learn as a matter of course. You already know several of these languages, even if you're only 14.
The person who asks me this question may be coming from another career. Or perhaps they are coming from a field like web development and they've figured out that HTML is only kind of like programming, and they'd like to try building something more substantial. But I especially hope that, if you are asking this question, you've realized that to be successful in computing, you need to teach yourself how to learn, and never stop learning.
The more I do this, the more it seems to me that software is more akin to writing than anything else. And we haven't figured out what makes a good writer, we only know when we like what someone writes. This is not some kind of engineering where all we have to do is put something in one end and turn the crank. It is tempting to think of software as deterministic -- that's what we want it to be, and that's the reason that we keep coming up with tools to help us produce the behavior we desire. But my experience keeps indicating the opposite, that it is more about people than processes, and the fact that it runs on a deterministic machine becomes less and less of an influence, just like the Heisenberg principle doesn't affect things on a human scale.
My father built custom homes, and in my youth I would occasionally work for him, mostly doing grunt labor and sometimes hanging sheet rock. He and his lead carpenter would tell me that they gave me these jobs for my own good -- so that I wouldn't go into the business. It worked.
So I can also use the analogy that building software is like building a house. We don't refer to everyone who works on a house as if they were exactly the same. There are concrete masons, roofers, plumbers, electricians, sheet rockers, plasterers, tile setters, laborers, rough carpenters, finish carpenters, and of course, general contractors. Each of these requires a different set of skills, which requires a different amount of time and effort to acquire. House-building is also subject to boom and bust cycles, like programming. If you want to get in quick, you might take a job as a laborer or a sheet rocker, where you can start getting paid without much of a learning curve. As long as demmand is strong, you have steady work, and your pay might even go up if there aren't enough people to do the work. But as soon as there's a downturn, carpenters and even the general contractor can hang the sheet rock themselves.
When the Internet was first booming, all you had to do was spend some time learning HTML and you could get a job and earn some pretty good money. When things turned down, however, it rapidly becomes clear that there is a hierarchy of desirable skills, and the HTML programmers (like the laborers and sheet rockers) go first, while the highly-skilled code smiths and carpenters are retained.
What I'm trying to say here is that you don't want to go into this business unless you are ready to commit to lifelong learning. Sometimes it seems like programming is a well-paying, reliable job -- but the only way you can make sure of this is if you are always making yourself more valuable.
Of course you can find exceptions. There are always those people who learn one language and are just competent enough and perhaps savvy enough to stay employed without doing much to expand their abilities. But they are surviving by luck, and they are ultimately vulnerable. To make yourself less vulnerable, you need to continuously improve your abilities, by reading, going to user groups, conferences, and seminars. The more depth you have in this field, the more valuable you will be, which means you have more stable job prospects and can command higher salaries.
Another approach is to look at the field in general, and find a place where you already have talents. For example, my brother is interested in software, and dabbles with it, but his business is in installing computers, fixing them and upgrading them. He's always been meticulous, so when he installs or fixes your computer you know that it will be in excellent shape when he's done; not just the software, but all the way down to the cables, which will be bundled neat and out of the way. He's always had more work than he could do, and he never noticed the dot-com bust. And needless to say, his work cannot be offshored.
I stayed in college a long time, and managed to get by in various ways. I even began a Ph.D. program at UCLA, which was mercifully cut short -- I say mercifully because I no longer loved being in college, and the reason I stayed in college for so long was because I enjoyed it so much. But what I enjoyed was typically the off-track stuff. Art and dance classes, working on the college newspaper, and even the handful of computer programming classes that I took (which were off-track because I was a physics undergrad and a computer engineering graduate student). Although I was far from exceptional academically (a delightful irony is that many colleges that would not have accepted me as a student now use my books in their courses!), I really enjoyed the life of the college student, and had I finished a Ph.D. I probably would have taken the easy path and ended up a professor.
But as it turns out, some of the greatest value that I got from college was from those same off-track courses, the ones that expanded my mind beyond "stuff we already know." I think this is especially true in computing because you are always programming to support some other goal, and the more you know about that goal the better you'll perform (I've encountered some European graduate programs that require the study of computing in combination with some other specialty, and you build your thesis by solving a domain-specific problem in that other specialty).
I also think that knowing more than just programming vastly improves your problem-solving skills (just as knowing more than one programming language vastly improves your programming skills). On multiple occasions I have encountered people, trained only in computer science, who seem to have more limits in their thinking than those who come from some other background, like math or physics, which requires more rigorous thinking and is less prone to "it works for me" solutions.
In one session a conference that I organized, one of the topics was to come up with a list of features for the ideal job candidate:
Learning as a lifestyle. For example, you should know more than one language; nothing opens your eyes more to the strengths and limitations of a language than learning another one.
Know where and how to get new knowledge.
Study prior art.
We are tool users.
Learn to do the simplest thing.
Understand the business (Read magazines. Start with Fast Company, which has very short and interesting articles. Then you can see if you want to read others)
You are personally responsible for errors. "It works for me" is not an acceptable strategy. Find your own bugs.
Become a leader: someone who communicates and inspires.
Who are you serving?
There is no right answer ... and always a better way. Show and discuss your code, without emotional attachment. You are not your code.
It's an asymptotic journey towards perfection.
Take whatever risks you can -- the best risks are the scary ones, but in trying you will feel more alive than you can imagine. It's best if you don't plan for a particular outcome, because you will often miss the true possibilities if you're too attached to a result. My best adventures have been ones that have started with "lets do a little experiment and see where it takes us.
Some people will be disappointed by this answer, and reply "yes, that's all very interesting and useful. But really, what should I learn? C++ or Java?" I'll fend these off by repeating here: I know it seems like all the ones and zeroes should make everything deterministic, so that such questions should have a simple answer, but they don't. It's not about making one choice and being done with it. It's about continuous learning and sometimes, bold choices. Trust me, your life will be more exciting this way.
In a future article (I'll post the link here when it's done), I will talk about the importance of understanding management and business issues, whether or not you ever plan to be a manager, and in that article I'll include a list of books that (even though they're about management) you should read to prepare yourself for your career.
Thanks for an interesting article, Bruce. I agree with most of your points, especially those about a commitment to lifelong self-directed learning. That's obviously a key component of success in this field.
I'm curious, though, why you think that software development cannot be like engineering. I definitely will not argue that it is not like engineering, but why can't it be?
It seems to me that incorporating more engineering-like processes and attitudes into the typical software development team would lead to more successful outcomes. Why is it that this industry has so many spectacular, ridiculous failures and boondoggles? There is certainly no technical reason for nearly all of these failures - they're all due to a breakdown in the way that people assemble complex systems. Isn't this the kind of thing that engineering addresses?
I like your article and I agree mostly about what you say. It assumes that the best qualified guy survives in the end. This was also for a long time my assumption and "business model". However, I got meanwhile scared from what I have seen in the last projects. People that can just do some Java coding, write some JSP pages, that actually write preatty procedural code, make the big bucks, because they know JSF, hibernate, Spring. Once you have those skills you play in the first league. General understanding of OOP, software development as such has little importance. During my studies I worked as a student assistant for the Fraunhofer institute in town on some software research project. Thought that would look good on my CV. But it didn't help at all in finding a job. If I had spent my time learning Struts instead I could have chosen between many job offers. I feel like software development work in the age of web development has become a mass product and skills beyond the basic ones to get some web app up and running are not in demand. This is what makes me think.
So I write my own little open source software (well, mostly for the fun of it), hoping somewhen someone when I apply for a job will realize that I can do more than just coding JSP pages. But I feel like that is an illusion. I will just be asked whether I know JSF, hibernate and Spring. What surely earns you credits is being accepted to some "famous" open source project from Apache. But then you really have to spend most of your spare time with those open source projects and there definitely is no time for kids or wife.
> General understanding of OOP, software development as such > has little importance. During my studies I worked as a > student assistant for the Fraunhofer institute in town on > some software research project. Thought that would look > good on my CV. But it didn't help at all in finding a job. > If I had spent my time learning Struts instead I could have > chosen between many job offers. I feel like software > development work in the age of web development has become > a mass product and skills beyond the basic ones to get > some web app up and running are not in demand. This is > what makes me think.
I share your pain. Personally I think we are in a weird pocket of time when deep computer skills (including programming) have actually been decreasing.
My theory is that during the dot-com bubble, talent became scarce and a lot tools were designed with the idea of making under-qualified people able to produce software. Along with these tools came a marketing message that no only did you not need really talented developers, but that they were more trouble than they were worth.
This has become ingrained. Management would rather have 12 developers who do repetitive typing and clicking instead of 1 really good developer who produces just as much (or more) but in ways they don't understand.
My hope is that we are on the tail end of this. It seems inevitable that this kind of thinking must go away. As a world, we are more dependent upon computers and software than ever before but I don't see a lot of young people wanting to understand how they really work. It must come to a head.
> Consider what he wrote: > > "This is not some kind of engineering where all we have to > do is put something in one end and turn the crank." > > Based on this quote, I would say that Bruce doesn't have > the slightest idea what engineers do. The idea that > engineering isn't creative is ludicrous.
Clearly not enough emphasis on "some kind." My BS was in applied physics (a physics degree + mechanical and electrical engineering; would have been a double major if I could have focused on one) and my MS was in computer engineering. Before becoming a consultant, I worked several years as an engineer. I even designed and built solar distillers.
However, there are some kinds of engineering which end up being "apply numbers and turn the crank." There are also jobs in programming which are not terribly creative -- my point is that these are day jobs but not career-quality jobs.
> Clearly not enough emphasis on "some kind." My BS was in > applied physics (a physics degree + mechanical and > electrical engineering; would have been a double major if > I could have focused on one) and my MS was in computer > engineering. Before becoming a consultant, I worked > several years as an engineer. I even designed and built > solar distillers.
I am glad you cleared that up. I think a lot of engineers would be insulted by that.
> However, there are some kinds of engineering which end up > being "apply numbers and turn the crank." There are also > jobs in programming which are not terribly creative -- my > point is that these are day jobs but not career-quality > jobs.
What frustrates me is that we have programmers that do things that could be done by computer programs. It's such a waste of resources.
> I'm curious, though, why you think that software > development cannot be like engineering. I definitely will > not argue that it is not like engineering, but why > can't it be?
Try comparing engineering projects and software projects of similar complexity and proximity to the bleeding edge. I suspect you will then find that the development budget for the engineering project is usually much higher.
Software development for life critical systems does seem to more closely approach physical engineering processes (and is typically very expensive). For regular software that approach seems to take too long and cost too much; the other guy whose software is merely good enough gets the business.
> Software development for life critical systems does seem > to more closely approach physical engineering processes > (and is typically very expensive). For regular software > that approach seems to take too long and cost too much; > the other guy whose software is merely good enough gets > the business.
This is what I'm trying to understand - why do people think that an engineering approach to software is more costly than a non-engineering approach? A good many software projects arrive 100% over budget and deadline. That doesn't even include the cost incurred after the launch of a system which doesn't deliver adequate value and imposes an ongoing operational/maintenance burden.
I didn't mean to derail this into a discussion of engineering vs. software development, however as someone planning where to go next in my career, I find it relevant.
> This is what I'm trying to understand - why do people > think that an engineering approach to software is more > costly than a non-engineering approach?
I attempted to address this above. There is this accepted idea that creating software is easy. How hard is it to throw together a app in Access or VB? I often tell people that anyone can write software that works when everything goes right. It's writing software that handles problems well that we get paid for. The problem is that a whole lot of people don't really understand this or even consider what could go wrong.
I'm being very abstract here so let me give you an example. I was recently explaining the need for a poison message queue in a message oriented architecture. The head of production support wanted a list of every possible error code and what could go wrong. I told him that was not possible and he thought I was full of shit. He didn't understand my design handled unexpected errors. Even Joel Spolsky doesn't understand exceptions and he's seen as an expert in some circles.
Frankly there are a lot of hacks and charlatans in the software and IT rackets and not enough people in management that understand software.
Personally, I think that software development and engineering (i.e. hardware development) are very closely similar. The biggest difference, I feel, is that the average quality of project control is much, much higher for hardware than software.
Engineering products are - generally - better designed, better developed, better tested and better delivered because the people who manage the processes are themselves experienced engineers who understand what it is that the grunts are doing and what it is that they should be doing.
In the software world, there is generally a dichotomy (with notable exceptions) between those giving the orders and those carrying them out. Most managers, in my experience, don't understand the software development process and those that do understand it seem to have a quite different understanding to that of software developers, and see it only from a management theory point of view.
Too many software developers, on the other hand, are just hackers with little or no understanding of what they are developing. Oh, they understand the code right enough but they think that "quality" and "unit tests" are the same thing and don't have any real empathy for the product or the market or the users, nor any useful understanding of the commercial realities that underpin their jobs and careers.
> Oh, they understand the code right enough but > they think that "quality" and "unit tests" are the same > thing and don't have any real empathy for the product or > the market or the users, nor any useful understanding of > the commercial realities that underpin their jobs and > careers.
I'm not entirely sure how much a chip designer shows empathy, cares for the users, the market, the commercial realities and so on. It's true though that my instinctive reaction to programmers who start to talk about professionalism, business needs, enterprise software etc. is to show me the code.
But anyway I worked in big corporations for long as a SW developer and they had quality management, large testing staff and the employees were well informed about business needs. Unit tests were practised sparingly though ...
I also don't know what "hacker" means these days? Many things to many people I guess. When Paul Graham talks about hackers it's a way of life, when process guys talk about them they become an uncontrollable variable and a strawman for everything that doesn't fit, when Hollywood shows them they are eccentric, often evil minded people with close to magical powers and when media cover them they are some sort of burglars with computers.
My advice to people thinking about coming into the field, whether as a change of careers or a student, is to figure out where you fit. Our field is expansive.
Not everyone enjoys thinking out solutions to problems and expressing the solution in code. There is still plenty of room. However, your choice of organizations becomes more narrow.
Small companies cannot have the overhead of specialization so splitting the developer role into business analyst, architect, project manager, sys admin, DBA, etc. cannot happen. In a small company and particularly a startup, you need to be a developer doing analysis, design, project management, etc. In these companies, time to market is generally more important than a high degree of correctness - ie. 80% is good enough. Software development is usually done rapidly with sketchy requirements and lots of refactoring. These organizations attract people who like to wear lots of hats, have lots of autonomy, and do rapid development.
Larger organizations allow for more specialization, so if writing code doesn't suit you, plenty of room for you to be an analyst, project manager, computer operator, and so on. However, you need to understand that many large organizations value weigh in from different departments so communication is a large overhead that often slows down development. Usually, the "Waterfall" practice suits these organizations better. (It's not a guarantee though. Certain industries move too rapidly.)
You need to figure out what suits you better. If, at the start of a project, booking > 50% of your time to meetings makes you agitated, stay away from organizations that foster group decision making. If being on call year round is not to your liking, startups should be avoided.
Don't get involved in ideology. Neither Waterfall nor Agile methods guarantee good software. It's about what methodology works better in your organization and ultimately having people committed to making a great product.
Bruce's advice on learning as a lifestyle cannot be overemphasized. Learning might be along the lines of new languages that allow greater abstraction or refactoring business processes for business improvement or tools for end users to produce their own reports or .... Always be curious.
Flat View: This topic has 24 replies
on 2 pages