I think that if jacquesm was living in Japan like patio11 (I also live in Japan), he wouldn't call himself a programmer either. Because a programmer in Japan is someone that takes a spec or a task, written by an engineer, and "translate" it into code. A programmer doesn't solve any problem, he implements another person solution, and that's it.
But at the end of the day it's not strictly about semantics, I think it's also about how you understand you work. When I don't introduce myself as an entrepreneur, I always introduce myself as a software engineer. Not out of elitism or anything like that, but because I think it carries more the fact that I am here to solve problems, and that programming is just one possible mean to this end.
I wonder what those specs written by engineers look like. How much details do they provide? Is the architecture of the project already specified? Algorithms and data structures already provided? If that's the case then wouldn't it be quicker for those engineers to directly type their specs in a high-level language? If that's not the case I think there are still a lot of problems for the programmer to solve.
I am a experienced programmer, too. No "software architect" or another label can convert the stupid into brilliant. In most cases is related to recognition, power, and pay, so may be that's the reason of accepting such labels as "normal" (I have no problem with others telling me X, Y or Z, although I find it non-sense as well).
I would argue that this semantic debate over the meaning of "programmer" is getting a tad tired. The author description would be more aptly described, in my opinion, as an entrepreneur.
Conflict management, and the other business-focused tasks he mention are completely separate from the programming side in the corporate world. I worked at a company where the software developers spent 90% of their time writing code based on tasks, and nearly no time on these other facets described in the article.
Suffice to say, I think that more focus should be spent on what people are doing, and not what they're calling it. Which is sort of what the author was saying, in the end.
Jacques mentioned in the article that someone doing COBOL gets paid megabucks, i did a very quick search on UK job sites for contractors and they seem to make the same day rate as PHP developers. Is it different elsewhere? Is it just in permanent jobs that it commands more money? Anyone know where and why COBOL gets the big bucks?
I know a guy (UK) who was able to retire after consulting for COBOL y2k compliance. I think big bucks were floating around back then at least, not sure about the current situation.
Personally, I think it's a myth. I did a lot of y2k work in cobol in '98-'99. It has been on my resume ever since then, but I've not had one recruiter call me up asking about my cobol skills, just my more recent java and db skills.
haha true....When I talk to women at Bars...I am an iPhone/iPad Artist....They dont realize that that involves tweaking LLVM flags and debugging segmentation faults haha!
The problem is, 'programming' as such is the end of a process. That process begins with talking to a customer about his or her idea/business problem, and asking questions and (basically) doing consulting to help the customer understand what his or her problem really is. Once that's clear, I write a proposal that outlines how I would address that problem, all in strictly high-level layman-understandable language - no mockups, no screenshots, no technical language, nothing. Then, once we agree on that, I contact a designer to help out with the design of the app, and to think about new and novels ways to make the interface as simple as possible. We show it to the customer, refine it, and get an agreement on all that stuff. And then, finally, three months since that first meeting, I can start with the programming.
So yes, I'm a programmer - but only if an academic is a writer, if an architect is someone who draws, and if a manager is someone who talks to people.
> The problem is, 'programming' as such is the end of a process.
In a lot of cases it's probably more accurate to say it's one part of the cycle. If programming really ends up being the end of the process, something might have gone wrong with the project.
Yeah ok ;-) The programming part itself is a whole different process, including a lot of communication with the customer. It is not really the end of the process in that sense - it's the last process in the big overarching process.
What I meant is just that after programming usually comes feedback, bug fixes, improvements, new features which need to be discussed, spec'd and developed and so on. In the sectors I've worked in (web and enterprise software), programming is part of an iterative process, so if the project is successful, it's not really the end of anything. It can be different in "heavier" sectors with projects that span over several years and that don't change much after the initial release.
>And then, finally, three months since that first meeting, I can start with the programming.
In my world (iOS), if it takes you three months to even start moving, you'll miss the market opportunities far too often. 3 months ago, iOS5 storyboarding and multitasking weren't even a concern and most developers were split between Xcode 3.x and 4.0!
There's an inverse snobbery in effect here to an extent.
If you've made it / made a name for yourself you can call yourself a programmer.
I don't know know whether it was the recently departed dmr or ken, but one of them answered 'programmer' when asked what he put as a profession on his landing/visa/immigration card.
That isn't because they were so big that they could say programmer, it is because that is what it used to be called before self-promotion inflated all job titles to the point of hyperbole.
The problem I have with Patrick's essay ("you are not a programmer") is that it addresses a situation that hardly any developer ever finds himself in. If I go to interview for an engineer position, it matters exactly not one bit that I try to pass myself off as a solutions architect or a business problem solver, except for possibly some awkward glances back and forth. All they want to know is how long I've been coding Blub, which frameworks I use and why did I quit my last job? If all is well I will start on Monday with checking out the SVN repo and start getting to know the code. Should I start trying to analyze the company's business processes that would be an awkward conversation indeed with the department manager.
I think that is the reality most developers find themselves in. I doubt it's been any different for Patrick until the consultancy spinoffs he can now pull on account of his personal brand.
So I kind of agree with Jacques here, with the exception that I don't call myself a programmer in conversation with people outside the field, since it sounds a bit like "punch card operator". That doesn't change the fact that I really am a programmer first and foremost.
Patrick's essay is for people who want more pay, recognition, and authority in a company that is not primarily a software company. If you aren't facing that particular problem, you don't need his solution. Hopefully you found it interesting anyway.
The problem I have with Patrick's essay ("you are not a programmer") is that it addresses a situation that hardly any developer ever finds himself in.
I think he was attempting to stress that the fact that developers don't find themselves in that situation is a little tragic. His essay suggests that in the right industries with somewhat more optimistic marketing the programmer's skillset is almost akin to magic. You take more responsibility for understanding how computers can solve problems, but by doing that become something irreplaceable.
The "reality" is context-limited, as are Patrick's suggestions. If you're willing to market more, though, Patrick's reality is pretty compelling.
a situation that hardly any developer ever finds himself in
"To a worm in horseradish, the world is horseradish."
(Sorry, have actual work to do today, so I'm going to reply mainly in epigrams where I can. ;)
pass myself off as... a business problem solver
Nobody is suggesting that. You don't pretend to solve problems for your business. At least, the business doesn't think so. They pay you. They don't pay people just for fun. They obviously think you're solving some kind of problem, right now.
Even within the seventh layer of a nine-layer bureaucracy, your peers have a problem that they are paying you to solve. Figure out what it is and learn to talk about that.
This needn't be self-aggrandizement, either. "I am one of ten interchangeable members of the QA team that keeps our customers happily renewing their subscriptions by finding bugs before they even see them" is fine. You needn't claim to walk on water all by yourself. People like loyal team players.
If you find that you can't talk about your problem without feeling dirty: That's a data point. If part of the job is "follow orders without thinking like a good little interchangeable part", that's a data point. If you discover that the problem you're solving is "win our division's internal war against the Other Division, customers be damned", you have a data point. If you come to the conclusion that you are in fact paid to cause problems, but the company can't figure that out because the intervening tangle of bureaucracy is disguising the fact, that's a data point. Try to keep doing your job well, but as the data points accumulate, and depending on your personality, you may find that other jobs are calling.
Nobody is suggesting that. You don't pretend to solve problems for your business. At least, the business doesn't think so. They pay you. They don't pay people just for fun. They obviously think you're solving some kind of problem, right now.
Well, often the 'problem' as such is "lack of programmers". The business value/problem has already defined by other people, and a solution decided on, and you need to code it. At least, that's the position I'd been in in the past. I might have come up with a clever algorithm that solved a particular internal problem on that project, but the overarching project being worked on wasn't really solving the original business problem that was presented. However, as lowly-coder-#17, no one really cares what your views are - the problem you're solving is manpower to implement someone else's vision, right or wrong.
> ... it matters exactly not one bit that I try to pass myself off as a solutions architect or a business problem solver, except for possibly some awkward glances back and forth.
Exactly, if he came to our shop to interview for an engineering position but would rather talk about making 'dreams come true' instead of algorithms or systems design, we would kindly show him towards the door.
Engineering shops don't like bullshit. If you are interviewing with HR sure, use business-speak all you want.
But perhaps the fact that there is even an HR dept. that will digest business speak like that, is a sign that you are interviewing at the wrong company.
He did not say give yourself a ridiculously fancy sounding title. He said tell them what you've done in the past and give yourself a title that engenders respect from your non-hacker friends. For example, if you tell people you are a software architect and you designed the system that made your company X million dollars, you will get respect.
If you don't spend at least some time thinking of your companies business processes then your just a non-thinking cog. Challenging these types of things is not only how you get ahead, but it's how you differentiate yourself from the non-thinking cogs.
It only gets respect because it's a kind of lie. You aren't an architect. You aren't an engineer. You write code, making up programs.
A secretary is a secretary. If people decided that's a bad thing to be, that's a shame. But it doesn't help to change the word to 'administrator,' which means something different.
I just think the debate about identifying oneself "as", like pointed by other comments, is specific to a cultural context. In India specifically "programming" is as much about sector of work like "Information Technology" as it would be individuals profession. So most of the time "programmer" or "software engineer" inter-changeably explains the where one works for someone outside the profession. In case the person shows further interest, one could go further into what exactly is the span of work. So unlike Patrick's essay tries to convey, "programmer" per se is not a restrictive definition.
Excellent post all in all, but the part I consider the most important is:
Job security, job satisfaction, good pay. Pick any two.
I've been keenly aware of that for a while now. For someone like me, someone who chooses the first two, it stings a lot until you come to terms with it and make it your conscious choice. It all has to do with one's priorities and no combination is bad in itself. You just need to be aware of these things or it might be a source of unhappiness for you.
Yes, me too, I'm a programmer. That's how I think of myself, regardless of what infinitely varied tasks I may do. And me too, that's what I blurt out when people ask me what I do.
In more formal contexts, like resumes and job apps, I call myself a software developer, because that's a more encompassing description of what I do. Software development is not just programming, even if that's the most obvious and the most fun part.
My employers call me whatever they want to call me. That's been technical staff member, programmer, software engineer, etc.
I never voluntarily call myself a software engineer. I've never worked under the supervision of a PE who was legally responsible for my work, and I've never been on a track working toward my PE. Very few software developers work in that environment.
I don't mind the informalization of the term software engineer, but I don't use it because I've never, ever worked in an environment where programming or software development was practiced as an engineering discipline using national or international standards of practice or product. Software development where I've been, and where most people are, is much more an individual art than a community science. So I don't want to give the impression that what I'm doing is in any way a legal, formal engineering practice.
The last point about in-formalisation of the discipline is not incidental. I think that it is sort of specific to the community that Hacker News hosts.
> I never voluntarily call myself a software engineer
I actually had my company change my official job title at one point in my career to "Software Developer". I have an undergraduate degree in engineering (partially because I wanted to rebel against my parent's wishes for me to do CS). Software cannot be engineered like a bridge. Structural engineering is very narrowly scoped. You have a design load, comprised of live loads like wind and moving cars and static loads from the weight of the structure itself. There are entire "cookbooks" of formulas used to compute the theoretical, accepted thickness of the support beams and bolts. There is standardized everything, from the project management terminology to the thread count on the bolts. After graduating, if you gain four years (in some states, less) of practical engineering experience, you can take the Professional Engineer (PE) exam. In some cases, to prove your experience, you need to submit three inches thick of paper calculations you have done while working. The PE exam is rigorous and graded on a curve. But once you pass, you get the pride and responsibility of having a seal that you can use to emboss blueprints. That says you take responsibility for the work. Software development is not engineering, and I have strong philosophical discussions with those programmers who insist on that term.
Software development is creative problem solving. You do not have much creativity in structural engineering.
It can be, as in the world of formal proofs and languages like Ada which facilitate them. It just typically isn't, as such formal procedures are far more costly and slower than than just dealing with bugs as they happen. For critical software systems like say avionics where a failure case is extremely costly (in both money and casualties), there do exist certification programs and rigorous methods as you describe for structural engineering.
It could be argued that avionics behaves more as engineering than as programming. Then we have a self-fulfilling definition: if we define fields with rigorous procedures as engineering, and fields without as software development, then of course software development doesn't have formalized methodology.
You're also comparing the largest scope of structural engineering - a massive bridge - with the entire spectrum of software. Engineering does happen on a smaller informalized scale too, like a homeowner building a shed or a Boy Scout troop building a rope obstacle course. That's still engineering, applying skills in carpentry or knot-tying to build something.
The problem I had with Patrick's essay is how derogatory it is to what we do.
I am a programmer because it's what I like to do. People pay me money to do it. And when I go home I read about it, talk to others about it, and I practice, practice, practice. I think about how I can write better software, reduce the amount of bugs, test better designs, and improve my productivity. I think about programming all of the time.
And like Jacques, I'm not afraid to tell others that I'm a programmer. I think most people understand what that is by now. I write programs for computers. If I say "Systems Analyst," or "Solution Architect," they will probably look at me funny and ask what that means. In an interview... it will probably be passed over without a second thought. So I call myself a programmer.
And I call myself a programmer with a bit of pride. It isn't an easy profession and involves far more than typing in a bunch of things that make computers do stuff. Experienced employers will have realized this before sitting some one such as myself down in an interview. They want someone with enthusiasm for the craft, the experience building many different systems, and the ability to learn. There was a time when I would have accepted any programming job. However there comes a point where talking to yet another company who just wants to replace a cog in their machine becomes a waste of your time. It is hard to be good at this job and experience and ability has a cost associated with them.
So yes, I am a programmer. Thanks Jacques for writing this.
The point of Patrick's essay isn't "Programming is lame" or "you shouldn't be proud of your programming accomplishments." How did anyone take that away?
> It isn't an easy profession and involves far more than typing in a bunch of things that make computers do stuff.
This is true. Nobody said that wasn't the case.
> I'm not afraid to tell others that I'm a programmer. I
> think most people understand what that is by now. I write
> programs for computers.
Look, I love writing code. I <3 proper testing. I take pride in my work and try to provide the best code I can possibly write.
That said, coding is what we do to achieve something. Maybe you're trying to make it easier for your support team to track tickets, or helping your client's customers save the most money.
I get that you're proud of your development skills, but at some point your software has to solve a business need, and you need to understand what the need is and how your software is solving it. All the unit tests and properly factored code won't mean anything if you don't. You'll write unnecessary features, or miss writing necessary ones.
Patrick's point as far as I understood it was that we all understand this but we're not billing ourselves that way. If I'm in an interview, or discussing my work with a non-technical associate, I emphasize my ability to understand business needs and write software to meet them. When I talk to technical folks, I emphasize that I unit- and integration-test all of my code and that I understand why DRY code is great.
> The problem I had with Patrick's essay is how derogatory
> it is to what we do.
On the contrary, I think it celebrated what we do. Not the technical aspects -- squeezing performance out of underpowered machines or designing remarkably simple architectures -- but the final outcomes. This app saved us millions per year. These new dashboard reports helped us earn 20% than expected this quarter.
“Programmer” sounds like “anomalously high-cost peon who types some mumbo-jumbo into some other mumbo-jumbo.” If you call yourself a programmer, someone is already working on a way to get you fired.
That sounds derogatory to me. His opinion is that business types could care less about what you do. You're not a programmer but an exploitable resource. Since when is being a crafts-person and being proud of your work and what you do bad?
I get that you're proud of your development skills, but at some point your software has to solve a business need, and you need to understand what the need is and how your software is solving it.
I'm in the business of producing good software. How does calling myself a programmer have anything to do with what you just said?
It's a matter of perception. Patrick thinks people think programmers are clueless navel-gazing cogs who don't have a grip on reality. Of course nothing could be further from the truth -- a good programmer is probably more in touch with the needs of the business than the ignorant stakeholder who thinks programmers just type in a bunch of stuff. I think this perception is a disservice to both programmers and business people alike. I do not doubt that there are people in the world who perceive programmers in the way Patrick describes... but I wouldn't work for them for anything less than a big six-figure salary and very gracious vacation allowance. I think most people understand that programmers make software and software solves problems for businesses and consumers which makes money. Therefore programmers must be pretty important.
So yes, I still call myself a programmer. If I catch wind that the person interviewing me views me as a 'peon' I walk. If that's what they're looking for it's their loss. They can figure it out later I'm sure and might come back to me when their spending 80% of their time and budget fixing the errors their "peon" introduced into their software.
Good programmers are hard to find. I don't see anything wrong with calling myself a programmer.
> Since when is being a crafts-person and being proud of
> your work and what you do bad?
Nobody said it was. Not the original article, not me, not anyone.
> I'm in the business of producing good software.
I don't know, maybe you are.
Right now, I'm in the healthcare business. My main client is a medicare company and they want people to sign up for their plans and fill prescriptions, preferably for the cheaper generics that save them money but still provide therapy required.
I meet those goals by writing well-architected software with solid test coverage. I make my job easier on myself by making my deployment a single-click affair. That's part of being a good developer, but that's not what I'm paid for. I'm paid to meet business goals. We got this client by writing software that meets those goals better than their original vendor. If someone comes along who writes poorly-architected messes but that achieve those goals better my client will leave me for them. I will be disgusted as a programmer that this happened, but it only makes sense.
> I don't see anything wrong with calling myself a programmer.
That's fine. Call yourself whatever you want. But -- and this is the entire point of Patrick's article! -- assuming that people understand the value of a good programmer is a mistake. Rather than dismissing folks who don't instantly comprehend your brilliance, maybe you might try explaining to them the value that you provide in terms they can understand.
If someone comes along who writes poorly-architected messes but that achieve those goals better my client will leave me for them. I will be disgusted as a programmer that this happened, but it only makes sense.
I understand what you're trying to say, but I disagree that people perceive "programmers" as highly-paid peons. If they did, why would you want to work for them? There are companies who are desperate for good programmers and recognize that good programmers are hard to come by. Negotiating with them is much less adversarial, I assure you.
I don't disagree with a lot of what you're saying. I think we can both agree that a good programmer understands their role in the business and should view their practice holistically as a part of a much bigger entity. However, I don't think that people universally see programmers as overly-paid gurus or what-have-you. Assuming they want skilled programmers to work for them, why would they look for replaceable cogs and peons?
The true cost of hiring those kinds of programmers will not be apparent until 5 years down the road when you're spending 80% of your budget and time fixing bugs and putting out fires from pissed off client who cannot believe you would ship them such a shoddy product.
Again.. maybe there are people in the world who still do not know what a programmer does or the value of hiring good programmers. I would argue that they're probably in the minority or hiring for a position that doesn't require a lot of skill. In that case perhaps Patrick is right -- but again, why would you want to work for them unless you're desperate to fill in your H1B requirements or you're straight out of school and have no experience. A good programmer can do a lot better in my experience.
I know that you're fighting the good fight, but I just don't have it in me to sell the concept that I'm going to produce software to solve someone's problems.
I'm only interested in joining teams where the decision to write high-quality software was already made - and I provide my skill to people who know that's what they need.
Job security, job satisfaction, good pay. Pick any two.
This statement doesn't make much sense when you think about it. It seems to be a lazy riff off of:
"Fast, cheap, quality: Pick any two"
Each of those characteristics are in competition with each other. Doing something fast often hurts quality and/or cheapness. Doing something cheaply may take longer and may harm quality.
Job security vs. job satisfaction don't really compete with each other. In fact, being more satisfied (i.e. happy) at your job may lead to better security indirectly, as a happy worker is a more productive, engaged, and charismatic worker.
Perhaps JMJ is trying to appeal to the commonly-held notion that fulfilling, satisfying jobs are ones that don't pay well - teaching, research, social work, etc. OK, it applies to certain sectors. But not across all sectors. A failure to recognize the inherent structural differences and opportunities between job fields (and public vs. private) hurts whatever rhetorical argument he's trying to make here.
"There are three things that mostly determine how well your life goes: what you're doing, who you're with, and where you are. If you can get two of the three right, you're ahead of 90% of the human race."
Sometimes there are tradeoffs between the three, sometimes not, but it's really, really hard to get all three to line up together.
Yes, and I'm sure that's what Jacques meant. Getting each of those qualities on their own can be difficult, but they are not in direct competition with each other. Nitpicky, maybe, but it's an important nuance.
In the limited context of tech jobs and entrepreneur, I don't think it's quite right to tell people that it's not possible to achieve all three. And it may even be counter-productive.
I agree "Programmer" is a sufficient job title, but my favourite "alternate" title I've seen anyone use is "Technical Enabler". It says "I use technology to solve problems and create value", which I think is very apt most of the time. You might be programming or you might simply be sharing/applying knowledge about computers, software, the web etc. that most people don't have. At least that's what I feel it's like most days.
Patrick's essay covered a lot of ground. It expanded on its title by explaining what companies value. The essay as a whole did not seem focused on job titles. The essay title did focus on job titles.
I see a wonderfully self-referential thing happening when people focus on the title of the essay. Maybe people do focus more on titles than they should -- both essay titles and job titles. Maybe job titles are as important as essay titles and email subject lines.
Patrick's essay was adaptibly engineered. If titles are what get through to people, the essay title will convey what's imprtant. Otherwise, the essay body will convey what's important.
Patrick's essay had nothing to do with titles. It was about describing what you do in terms of the benefit you provide to your customers/employers rather than in terms of the skills or tools you use to provide that benefit.
I could tell people I can program Excel interop in .NET, or I could tell them I saved my company dozens of hours a week by automating an administrative process. To non-programmers, only one of these descriptions sounds interesting. A programmer can hear "Excel interop in .NET" and infer automating administrative tasks. A business person, generally, cannot.
Patrick's essay was about being explicit about the value you provide, not about picking a fancier name for yourself.
I feel that is the wrong way to approach things. Your job as a programmer was to provide that deliverable as set out by your position. You programmed it and it went along. The outcome of that deliverable was the improvement but your job was to construct it.
I don't pretend that my past jobs were "automating IPTV interface interactions" or "enabling alternative business transaction venues"... I was programming what was needed. Its a white lie the industry has gotten comfortable with and I think we'd be better off if this path was never went down in the first place. People prettying up their titles have essentially "robbed" honest ones ("I'm a f*king programmer") from being treated in the same regard.
I agree with you completely. I'm just being pissy and saying "I wish things were different" and I really don't have a productive solution to the problem... My wish is that programmers would take pride in the title and call themselves programmers who were able to accomplish X and Y for company Z and not the other way around where they hide the programmer bit.
Do you think CNC operators give a damn whether most people know what a CNC operator does?
This "make people understand what exactly I do and how much value I provide and how precious I am" is yet another manifestation of insecurity of software developers.
No, unless they work or want to work directly with CNC operators and need to know what they're actually capable of instead of just what they're called.
This is exactly what you don't put out a 'I need a dozen programmers' ad - people aren't a fungible commodity. You do actually need to know how much value they can provide.
"Make people understand what exactly I do" is exactly the attitude I think Patrick is arguing against. That's why you don't call yourself a programmer or talk about what technologies you use. Because it doesn't matter to non-software companies. What matters is whether you can save the company money or increase their revenue.
Calling yourself a programmer is telling what you do. Describing how many hours of work you can save is telling how you can provide value.
When presented with a bunch of employees manually copying information from spreadsheet into a database, you can tell them, "I know Excel interop and SQL," or you can tell them, "I can make it so you never have to manually copy this information again." Only one of these statements is interesting to a non-programmer. The first implies the second to us, but not to a non-programmer, so you need to be explicit. You can't expect them to make the inference and present you with a spec for a spreadsheet-parsing, database-updating program.
The reason programmers have to learn this and not CNC operators is that the benefit of a CNC operator is much better understood in their sphere (manufacturing) than the benefit of a programmer is understood in their sphere (almost anywhere computers are used extensively). Most people who can benefit from a CNC operator know it and know how. Most people (outside of the software industry) who can benefit from a programmer don't know it and even if they did, wouldn't know how.
Programming is by no means the only field in which this applies though. It also applies in design, copy-writing, SEO, ergonomics, preventative medicine, and many other fields. Anywhere where the people who can benefit from a field's work don't understand the field's work, but do understand impact to their bottom line.
If you pitch a business with, "I increased productivity at another business by 10%," you'll have better results (at least this is the conjecture at hand) than if you pitch with, "I'm an ergonomics expert," even though the actual work being offered is the same. Either way, the business owners will probably never understand that ergonomics is more than adjusting desk height. But they don't, and shouldn't, need to. They just need to appreciate how it helps their bottom line and trust the experts to apply the expertise where it should be applied.
Trying to make people understand what you do is exactly the problem. Programmers naturally seem to want people to understand how computers work and what they can do. We want people to understand what code is, why it's important that it's written well, and so many other things that business owners simply shouldn't need to care about. That's why we tell people we're programmers, or that we know certain languages or frameworks. These things are only relevant to other programmers though. Business owners care about making money, so tell them how you can do that.
It is hard for those of us who know how to tinker to appreciate that there really are folks who don't tinker.
You assign them to pull the levers, and they pull the levers. If the machine they're running is manifestly inefficient, they don't notice, or they pretend not to notice.
(Or – if they're good – they adapt themselves, adopting a complex series of difficult physical and mental moves to compensate for the machine's brokenness. Sometimes those physical moves are such that, after four years on the job, they'll be in the hospital. But they do them anyway, because, hey, making the inefficient machine work is their job.)
If the machine next to theirs is broken in a way such that it messes up half of the work coming out of their machine, they just keep going -- hey, it's their job to run this machine, not that machine. If the machine they're running breaks down, they call for help and then sit there unmoving until help arrives. ("I didn't want to break anything.")
You tell them to RTFM, and they do, all of it, and then they come back to you: "I read the whole manual; now what do you want me to do?"
They may have even memorized the manual. It's not that these people aren't smart and eager to please. Indeed – and this is the thing I have trouble getting my head around – sometimes, within their area of expertise, they may know how to tinker like mad, they know the freaking serial numbers of every part of their machine and which ones can substitute for each other in an emergency. And yet, beyond their area, there's this strange paralysis. You hand them the duct tape and gesture encouragingly at a neighboring machine and... nothing happens.
If you give such a person a room full of miscellaneous broken things and ask them to fix everything they will proceed at a rate of (1 + epsilon) hour of progress per hour you spend telling them what to do. On the flip side, if you give them a room full of ten thousand widgets to finagle and they have a certification in Widget Finagling, those widgets will get finagled. They might even work overtime to please you. And when the widgets are done they'll go home, even if the rest of the factory is on fire, because there's nothing left for them to do.
When hiring someone to solve our problems we desperately need to know whether or not we're getting a hacker, or a technician. Both have their roles, but they can't substitute for each other.
As a ground rule, as long as you are calling other peoples modules you're not yet programming, but that doesn't mean that what you do can't be meaningful or useful.
Oh, I see. Do I also have to code my own compiler before I start rewriting glibc?
The problem I have with "software engineering" is that it's not real engineering. Sure you might do thinking to create proper requirements, design, build a prototype, build the real thing and iterate, use agile or whatever.
But comparing programming to actual, real-world engineering is a different kettle of fish. Engineers make things with actual physical requirements - if they're not met, people will die. You're not going to be doing proper engineering unless you can sue the engineers for the wholes in their software that caused people to lose money from their bank. Sure it works and may well solve a problem, but it's not engineered.
Real software engineering is using formal methods to do your utmost to prove that your stuff actually will work (Intel does that for some of their chip development) or make 5 different control systems for your rocket and have them vote on the correct course to add extra backup to prevent fuckups (NASA did this for the Apollo iirc - the EU Ariane didn't, so they had a rocket crash at one point).
Until that happens, you're just going to be developing sandcastles - you're going to have buggy software that will break at some point - because software development is so fast that it's not worth the effort to engineer from the get-go.
In other words, coding is coding - you can have good coding that uses best practices - but if you call it engineering you're deluding yourself in most cases.
Bad code won't kill people? I think any longtime reader of HN can think of a few real-life stories that would contradict this.
I studied computer engineering and yes, I remember those of us more on the hardware side thinking the ones on the "soft" side of the engineering were the lazy ones. Having been more involved in programming projects since then, I've seen the great value in being able to "engineer" software that meets highly specific specs and anticipates future needs, upgrades, and maintenance. Neither of those are necessarily related to good programming, and the failure to achieve both in mission-critical software will lead to deaths
* and as far as I can tell, "real" engineers do not get individually sued for physical failures, unless there's a rare instance in which an individual engineer can be proven to be malicious or grossly negligent.
I was thinking more of the web stuff that people do, so may be overstating my case. There are cases where you really need to make things safe - NASA's Apollo rockets and medical equipment to name a few. Also, when I talk about suing engineers I meant suing a big company such as Microsoft for the glaring security problems in earlier versions of Windows. Some Windows machines would be hacked within minutes of connecting them to the internet - in my mind that's simply negligence on the part of the developers - them being liable for creating an insecure product would force them to develop a properly secure solution - in other words to actually engineer it properly.
Where you have a hardware-centric approach, I'd assume that the whole system, software included has been pretty well tested and engineered to a great deal.
But banking software and I postulate most software that hacker news contributors write is probably going to be inherently flaky in some respect. The main fault for this is that writing software is so quick and easy compared to creating something physical that will last.
It's due to the push to get something to market and the "easy" nature of software development that leaves true engineering discipline by the wayside.
Yes, you can be in a situation (especially when people's lives depend on it directly such as medical equipment) when you are properly engineering a solution, but I still stand by my premise that most software development is not software engineering - you're just making sandcastles.
> Some Windows machines would be hacked within minutes of connecting them to the internet - in my mind that's simply negligence on the part of the developers - them being liable for creating an insecure product would force them to develop a properly secure solution - in other words to actually engineer it properly.
If software developers were actually engineers, or at least some of them were and were required to sign off, they would actually have authority to influence decisions that had huge impact on this situation - deprioritizing of security, bad project management, etc, not originating from the development side of the organization.
The title makes it sound as if the author is in complete disagreement with Patrick's essay (and perhaps he feels that he is) but it's not how I see it.
Both articles are about the way you present yourself, not really about the "programmer" label. Sure, your label is part of what do for a living, but the important point brought up by both articles is that you have to recognize what your value is in the workplace and use that as your selling point in order to achieve job satisfaction and/or recognition (that's the way I understood them anyway).
129 comments
[ 3.6 ms ] story [ 203 ms ] threadBut at the end of the day it's not strictly about semantics, I think it's also about how you understand you work. When I don't introduce myself as an entrepreneur, I always introduce myself as a software engineer. Not out of elitism or anything like that, but because I think it carries more the fact that I am here to solve problems, and that programming is just one possible mean to this end.
Look at their dueling blog posts! LOL! Nerds!
http://www.joelonsoftware.com/articles/fog0000000018.html
Conflict management, and the other business-focused tasks he mention are completely separate from the programming side in the corporate world. I worked at a company where the software developers spent 90% of their time writing code based on tasks, and nearly no time on these other facets described in the article.
Suffice to say, I think that more focus should be spent on what people are doing, and not what they're calling it. Which is sort of what the author was saying, in the end.
The problem is, 'programming' as such is the end of a process. That process begins with talking to a customer about his or her idea/business problem, and asking questions and (basically) doing consulting to help the customer understand what his or her problem really is. Once that's clear, I write a proposal that outlines how I would address that problem, all in strictly high-level layman-understandable language - no mockups, no screenshots, no technical language, nothing. Then, once we agree on that, I contact a designer to help out with the design of the app, and to think about new and novels ways to make the interface as simple as possible. We show it to the customer, refine it, and get an agreement on all that stuff. And then, finally, three months since that first meeting, I can start with the programming.
So yes, I'm a programmer - but only if an academic is a writer, if an architect is someone who draws, and if a manager is someone who talks to people.
In a lot of cases it's probably more accurate to say it's one part of the cycle. If programming really ends up being the end of the process, something might have gone wrong with the project.
In my world (iOS), if it takes you three months to even start moving, you'll miss the market opportunities far too often. 3 months ago, iOS5 storyboarding and multitasking weren't even a concern and most developers were split between Xcode 3.x and 4.0!
Apples, meet oranges.
I don't know know whether it was the recently departed dmr or ken, but one of them answered 'programmer' when asked what he put as a profession on his landing/visa/immigration card.
I think that is the reality most developers find themselves in. I doubt it's been any different for Patrick until the consultancy spinoffs he can now pull on account of his personal brand.
So I kind of agree with Jacques here, with the exception that I don't call myself a programmer in conversation with people outside the field, since it sounds a bit like "punch card operator". That doesn't change the fact that I really am a programmer first and foremost.
I think he was attempting to stress that the fact that developers don't find themselves in that situation is a little tragic. His essay suggests that in the right industries with somewhat more optimistic marketing the programmer's skillset is almost akin to magic. You take more responsibility for understanding how computers can solve problems, but by doing that become something irreplaceable.
The "reality" is context-limited, as are Patrick's suggestions. If you're willing to market more, though, Patrick's reality is pretty compelling.
"To a worm in horseradish, the world is horseradish."
(Sorry, have actual work to do today, so I'm going to reply mainly in epigrams where I can. ;)
pass myself off as... a business problem solver
Nobody is suggesting that. You don't pretend to solve problems for your business. At least, the business doesn't think so. They pay you. They don't pay people just for fun. They obviously think you're solving some kind of problem, right now.
Even within the seventh layer of a nine-layer bureaucracy, your peers have a problem that they are paying you to solve. Figure out what it is and learn to talk about that.
This needn't be self-aggrandizement, either. "I am one of ten interchangeable members of the QA team that keeps our customers happily renewing their subscriptions by finding bugs before they even see them" is fine. You needn't claim to walk on water all by yourself. People like loyal team players.
If you find that you can't talk about your problem without feeling dirty: That's a data point. If part of the job is "follow orders without thinking like a good little interchangeable part", that's a data point. If you discover that the problem you're solving is "win our division's internal war against the Other Division, customers be damned", you have a data point. If you come to the conclusion that you are in fact paid to cause problems, but the company can't figure that out because the intervening tangle of bureaucracy is disguising the fact, that's a data point. Try to keep doing your job well, but as the data points accumulate, and depending on your personality, you may find that other jobs are calling.
Well, often the 'problem' as such is "lack of programmers". The business value/problem has already defined by other people, and a solution decided on, and you need to code it. At least, that's the position I'd been in in the past. I might have come up with a clever algorithm that solved a particular internal problem on that project, but the overarching project being worked on wasn't really solving the original business problem that was presented. However, as lowly-coder-#17, no one really cares what your views are - the problem you're solving is manpower to implement someone else's vision, right or wrong.
Exactly, if he came to our shop to interview for an engineering position but would rather talk about making 'dreams come true' instead of algorithms or systems design, we would kindly show him towards the door.
Engineering shops don't like bullshit. If you are interviewing with HR sure, use business-speak all you want.
But perhaps the fact that there is even an HR dept. that will digest business speak like that, is a sign that you are interviewing at the wrong company.
He did not say give yourself a ridiculously fancy sounding title. He said tell them what you've done in the past and give yourself a title that engenders respect from your non-hacker friends. For example, if you tell people you are a software architect and you designed the system that made your company X million dollars, you will get respect.
If you don't spend at least some time thinking of your companies business processes then your just a non-thinking cog. Challenging these types of things is not only how you get ahead, but it's how you differentiate yourself from the non-thinking cogs.
A secretary is a secretary. If people decided that's a bad thing to be, that's a shame. But it doesn't help to change the word to 'administrator,' which means something different.
Job security, job satisfaction, good pay. Pick any two.
I've been keenly aware of that for a while now. For someone like me, someone who chooses the first two, it stings a lot until you come to terms with it and make it your conscious choice. It all has to do with one's priorities and no combination is bad in itself. You just need to be aware of these things or it might be a source of unhappiness for you.
In more formal contexts, like resumes and job apps, I call myself a software developer, because that's a more encompassing description of what I do. Software development is not just programming, even if that's the most obvious and the most fun part.
My employers call me whatever they want to call me. That's been technical staff member, programmer, software engineer, etc.
I never voluntarily call myself a software engineer. I've never worked under the supervision of a PE who was legally responsible for my work, and I've never been on a track working toward my PE. Very few software developers work in that environment.
I don't mind the informalization of the term software engineer, but I don't use it because I've never, ever worked in an environment where programming or software development was practiced as an engineering discipline using national or international standards of practice or product. Software development where I've been, and where most people are, is much more an individual art than a community science. So I don't want to give the impression that what I'm doing is in any way a legal, formal engineering practice.
I actually had my company change my official job title at one point in my career to "Software Developer". I have an undergraduate degree in engineering (partially because I wanted to rebel against my parent's wishes for me to do CS). Software cannot be engineered like a bridge. Structural engineering is very narrowly scoped. You have a design load, comprised of live loads like wind and moving cars and static loads from the weight of the structure itself. There are entire "cookbooks" of formulas used to compute the theoretical, accepted thickness of the support beams and bolts. There is standardized everything, from the project management terminology to the thread count on the bolts. After graduating, if you gain four years (in some states, less) of practical engineering experience, you can take the Professional Engineer (PE) exam. In some cases, to prove your experience, you need to submit three inches thick of paper calculations you have done while working. The PE exam is rigorous and graded on a curve. But once you pass, you get the pride and responsibility of having a seal that you can use to emboss blueprints. That says you take responsibility for the work. Software development is not engineering, and I have strong philosophical discussions with those programmers who insist on that term.
Software development is creative problem solving. You do not have much creativity in structural engineering.
It can be, as in the world of formal proofs and languages like Ada which facilitate them. It just typically isn't, as such formal procedures are far more costly and slower than than just dealing with bugs as they happen. For critical software systems like say avionics where a failure case is extremely costly (in both money and casualties), there do exist certification programs and rigorous methods as you describe for structural engineering.
It could be argued that avionics behaves more as engineering than as programming. Then we have a self-fulfilling definition: if we define fields with rigorous procedures as engineering, and fields without as software development, then of course software development doesn't have formalized methodology.
You're also comparing the largest scope of structural engineering - a massive bridge - with the entire spectrum of software. Engineering does happen on a smaller informalized scale too, like a homeowner building a shed or a Boy Scout troop building a rope obstacle course. That's still engineering, applying skills in carpentry or knot-tying to build something.
I am a programmer because it's what I like to do. People pay me money to do it. And when I go home I read about it, talk to others about it, and I practice, practice, practice. I think about how I can write better software, reduce the amount of bugs, test better designs, and improve my productivity. I think about programming all of the time.
And like Jacques, I'm not afraid to tell others that I'm a programmer. I think most people understand what that is by now. I write programs for computers. If I say "Systems Analyst," or "Solution Architect," they will probably look at me funny and ask what that means. In an interview... it will probably be passed over without a second thought. So I call myself a programmer.
And I call myself a programmer with a bit of pride. It isn't an easy profession and involves far more than typing in a bunch of things that make computers do stuff. Experienced employers will have realized this before sitting some one such as myself down in an interview. They want someone with enthusiasm for the craft, the experience building many different systems, and the ability to learn. There was a time when I would have accepted any programming job. However there comes a point where talking to yet another company who just wants to replace a cog in their machine becomes a waste of your time. It is hard to be good at this job and experience and ability has a cost associated with them.
So yes, I am a programmer. Thanks Jacques for writing this.
That said, coding is what we do to achieve something. Maybe you're trying to make it easier for your support team to track tickets, or helping your client's customers save the most money.
I get that you're proud of your development skills, but at some point your software has to solve a business need, and you need to understand what the need is and how your software is solving it. All the unit tests and properly factored code won't mean anything if you don't. You'll write unnecessary features, or miss writing necessary ones.
Patrick's point as far as I understood it was that we all understand this but we're not billing ourselves that way. If I'm in an interview, or discussing my work with a non-technical associate, I emphasize my ability to understand business needs and write software to meet them. When I talk to technical folks, I emphasize that I unit- and integration-test all of my code and that I understand why DRY code is great.
On the contrary, I think it celebrated what we do. Not the technical aspects -- squeezing performance out of underpowered machines or designing remarkably simple architectures -- but the final outcomes. This app saved us millions per year. These new dashboard reports helped us earn 20% than expected this quarter.That sounds derogatory to me. His opinion is that business types could care less about what you do. You're not a programmer but an exploitable resource. Since when is being a crafts-person and being proud of your work and what you do bad?
I get that you're proud of your development skills, but at some point your software has to solve a business need, and you need to understand what the need is and how your software is solving it.
I'm in the business of producing good software. How does calling myself a programmer have anything to do with what you just said?
It's a matter of perception. Patrick thinks people think programmers are clueless navel-gazing cogs who don't have a grip on reality. Of course nothing could be further from the truth -- a good programmer is probably more in touch with the needs of the business than the ignorant stakeholder who thinks programmers just type in a bunch of stuff. I think this perception is a disservice to both programmers and business people alike. I do not doubt that there are people in the world who perceive programmers in the way Patrick describes... but I wouldn't work for them for anything less than a big six-figure salary and very gracious vacation allowance. I think most people understand that programmers make software and software solves problems for businesses and consumers which makes money. Therefore programmers must be pretty important.
So yes, I still call myself a programmer. If I catch wind that the person interviewing me views me as a 'peon' I walk. If that's what they're looking for it's their loss. They can figure it out later I'm sure and might come back to me when their spending 80% of their time and budget fixing the errors their "peon" introduced into their software.
Good programmers are hard to find. I don't see anything wrong with calling myself a programmer.
Right now, I'm in the healthcare business. My main client is a medicare company and they want people to sign up for their plans and fill prescriptions, preferably for the cheaper generics that save them money but still provide therapy required.
I meet those goals by writing well-architected software with solid test coverage. I make my job easier on myself by making my deployment a single-click affair. That's part of being a good developer, but that's not what I'm paid for. I'm paid to meet business goals. We got this client by writing software that meets those goals better than their original vendor. If someone comes along who writes poorly-architected messes but that achieve those goals better my client will leave me for them. I will be disgusted as a programmer that this happened, but it only makes sense.
That's fine. Call yourself whatever you want. But -- and this is the entire point of Patrick's article! -- assuming that people understand the value of a good programmer is a mistake. Rather than dismissing folks who don't instantly comprehend your brilliance, maybe you might try explaining to them the value that you provide in terms they can understand.I understand what you're trying to say, but I disagree that people perceive "programmers" as highly-paid peons. If they did, why would you want to work for them? There are companies who are desperate for good programmers and recognize that good programmers are hard to come by. Negotiating with them is much less adversarial, I assure you.
I don't disagree with a lot of what you're saying. I think we can both agree that a good programmer understands their role in the business and should view their practice holistically as a part of a much bigger entity. However, I don't think that people universally see programmers as overly-paid gurus or what-have-you. Assuming they want skilled programmers to work for them, why would they look for replaceable cogs and peons?
The true cost of hiring those kinds of programmers will not be apparent until 5 years down the road when you're spending 80% of your budget and time fixing bugs and putting out fires from pissed off client who cannot believe you would ship them such a shoddy product.
Again.. maybe there are people in the world who still do not know what a programmer does or the value of hiring good programmers. I would argue that they're probably in the minority or hiring for a position that doesn't require a lot of skill. In that case perhaps Patrick is right -- but again, why would you want to work for them unless you're desperate to fill in your H1B requirements or you're straight out of school and have no experience. A good programmer can do a lot better in my experience.
This statement doesn't make much sense when you think about it. It seems to be a lazy riff off of:
"Fast, cheap, quality: Pick any two"
Each of those characteristics are in competition with each other. Doing something fast often hurts quality and/or cheapness. Doing something cheaply may take longer and may harm quality.
Job security vs. job satisfaction don't really compete with each other. In fact, being more satisfied (i.e. happy) at your job may lead to better security indirectly, as a happy worker is a more productive, engaged, and charismatic worker.
Perhaps JMJ is trying to appeal to the commonly-held notion that fulfilling, satisfying jobs are ones that don't pay well - teaching, research, social work, etc. OK, it applies to certain sectors. But not across all sectors. A failure to recognize the inherent structural differences and opportunities between job fields (and public vs. private) hurts whatever rhetorical argument he's trying to make here.
"There are three things that mostly determine how well your life goes: what you're doing, who you're with, and where you are. If you can get two of the three right, you're ahead of 90% of the human race."
Sometimes there are tradeoffs between the three, sometimes not, but it's really, really hard to get all three to line up together.
In the limited context of tech jobs and entrepreneur, I don't think it's quite right to tell people that it's not possible to achieve all three. And it may even be counter-productive.
I see a wonderfully self-referential thing happening when people focus on the title of the essay. Maybe people do focus more on titles than they should -- both essay titles and job titles. Maybe job titles are as important as essay titles and email subject lines.
Patrick's essay was adaptibly engineered. If titles are what get through to people, the essay title will convey what's imprtant. Otherwise, the essay body will convey what's important.
I could tell people I can program Excel interop in .NET, or I could tell them I saved my company dozens of hours a week by automating an administrative process. To non-programmers, only one of these descriptions sounds interesting. A programmer can hear "Excel interop in .NET" and infer automating administrative tasks. A business person, generally, cannot.
Patrick's essay was about being explicit about the value you provide, not about picking a fancier name for yourself.
I don't pretend that my past jobs were "automating IPTV interface interactions" or "enabling alternative business transaction venues"... I was programming what was needed. Its a white lie the industry has gotten comfortable with and I think we'd be better off if this path was never went down in the first place. People prettying up their titles have essentially "robbed" honest ones ("I'm a f*king programmer") from being treated in the same regard.
Saying what you did, and better, what that actually accomplished in real world terms isn't a lie at all, it's what people actually care about.
This "make people understand what exactly I do and how much value I provide and how precious I am" is yet another manifestation of insecurity of software developers.
This is exactly what you don't put out a 'I need a dozen programmers' ad - people aren't a fungible commodity. You do actually need to know how much value they can provide.
Calling yourself a programmer is telling what you do. Describing how many hours of work you can save is telling how you can provide value.
When presented with a bunch of employees manually copying information from spreadsheet into a database, you can tell them, "I know Excel interop and SQL," or you can tell them, "I can make it so you never have to manually copy this information again." Only one of these statements is interesting to a non-programmer. The first implies the second to us, but not to a non-programmer, so you need to be explicit. You can't expect them to make the inference and present you with a spec for a spreadsheet-parsing, database-updating program.
The reason programmers have to learn this and not CNC operators is that the benefit of a CNC operator is much better understood in their sphere (manufacturing) than the benefit of a programmer is understood in their sphere (almost anywhere computers are used extensively). Most people who can benefit from a CNC operator know it and know how. Most people (outside of the software industry) who can benefit from a programmer don't know it and even if they did, wouldn't know how.
Programming is by no means the only field in which this applies though. It also applies in design, copy-writing, SEO, ergonomics, preventative medicine, and many other fields. Anywhere where the people who can benefit from a field's work don't understand the field's work, but do understand impact to their bottom line.
If you pitch a business with, "I increased productivity at another business by 10%," you'll have better results (at least this is the conjecture at hand) than if you pitch with, "I'm an ergonomics expert," even though the actual work being offered is the same. Either way, the business owners will probably never understand that ergonomics is more than adjusting desk height. But they don't, and shouldn't, need to. They just need to appreciate how it helps their bottom line and trust the experts to apply the expertise where it should be applied.
Trying to make people understand what you do is exactly the problem. Programmers naturally seem to want people to understand how computers work and what they can do. We want people to understand what code is, why it's important that it's written well, and so many other things that business owners simply shouldn't need to care about. That's why we tell people we're programmers, or that we know certain languages or frameworks. These things are only relevant to other programmers though. Business owners care about making money, so tell them how you can do that.
You assign them to pull the levers, and they pull the levers. If the machine they're running is manifestly inefficient, they don't notice, or they pretend not to notice.
(Or – if they're good – they adapt themselves, adopting a complex series of difficult physical and mental moves to compensate for the machine's brokenness. Sometimes those physical moves are such that, after four years on the job, they'll be in the hospital. But they do them anyway, because, hey, making the inefficient machine work is their job.)
If the machine next to theirs is broken in a way such that it messes up half of the work coming out of their machine, they just keep going -- hey, it's their job to run this machine, not that machine. If the machine they're running breaks down, they call for help and then sit there unmoving until help arrives. ("I didn't want to break anything.")
You tell them to RTFM, and they do, all of it, and then they come back to you: "I read the whole manual; now what do you want me to do?"
They may have even memorized the manual. It's not that these people aren't smart and eager to please. Indeed – and this is the thing I have trouble getting my head around – sometimes, within their area of expertise, they may know how to tinker like mad, they know the freaking serial numbers of every part of their machine and which ones can substitute for each other in an emergency. And yet, beyond their area, there's this strange paralysis. You hand them the duct tape and gesture encouragingly at a neighboring machine and... nothing happens.
If you give such a person a room full of miscellaneous broken things and ask them to fix everything they will proceed at a rate of (1 + epsilon) hour of progress per hour you spend telling them what to do. On the flip side, if you give them a room full of ten thousand widgets to finagle and they have a certification in Widget Finagling, those widgets will get finagled. They might even work overtime to please you. And when the widgets are done they'll go home, even if the rest of the factory is on fire, because there's nothing left for them to do.
When hiring someone to solve our problems we desperately need to know whether or not we're getting a hacker, or a technician. Both have their roles, but they can't substitute for each other.
So you base this on whether someone calls themselves a programmer or not?
Now I feel like a Geico caveman.
Oh, I see. Do I also have to code my own compiler before I start rewriting glibc?
But comparing programming to actual, real-world engineering is a different kettle of fish. Engineers make things with actual physical requirements - if they're not met, people will die. You're not going to be doing proper engineering unless you can sue the engineers for the wholes in their software that caused people to lose money from their bank. Sure it works and may well solve a problem, but it's not engineered.
Real software engineering is using formal methods to do your utmost to prove that your stuff actually will work (Intel does that for some of their chip development) or make 5 different control systems for your rocket and have them vote on the correct course to add extra backup to prevent fuckups (NASA did this for the Apollo iirc - the EU Ariane didn't, so they had a rocket crash at one point).
Until that happens, you're just going to be developing sandcastles - you're going to have buggy software that will break at some point - because software development is so fast that it's not worth the effort to engineer from the get-go.
In other words, coding is coding - you can have good coding that uses best practices - but if you call it engineering you're deluding yourself in most cases.
Bad code won't kill people? I think any longtime reader of HN can think of a few real-life stories that would contradict this.
I studied computer engineering and yes, I remember those of us more on the hardware side thinking the ones on the "soft" side of the engineering were the lazy ones. Having been more involved in programming projects since then, I've seen the great value in being able to "engineer" software that meets highly specific specs and anticipates future needs, upgrades, and maintenance. Neither of those are necessarily related to good programming, and the failure to achieve both in mission-critical software will lead to deaths
* and as far as I can tell, "real" engineers do not get individually sued for physical failures, unless there's a rare instance in which an individual engineer can be proven to be malicious or grossly negligent.
Where you have a hardware-centric approach, I'd assume that the whole system, software included has been pretty well tested and engineered to a great deal.
But banking software and I postulate most software that hacker news contributors write is probably going to be inherently flaky in some respect. The main fault for this is that writing software is so quick and easy compared to creating something physical that will last.
It's due to the push to get something to market and the "easy" nature of software development that leaves true engineering discipline by the wayside.
Yes, you can be in a situation (especially when people's lives depend on it directly such as medical equipment) when you are properly engineering a solution, but I still stand by my premise that most software development is not software engineering - you're just making sandcastles.
If software developers were actually engineers, or at least some of them were and were required to sign off, they would actually have authority to influence decisions that had huge impact on this situation - deprioritizing of security, bad project management, etc, not originating from the development side of the organization.
Both articles are about the way you present yourself, not really about the "programmer" label. Sure, your label is part of what do for a living, but the important point brought up by both articles is that you have to recognize what your value is in the workplace and use that as your selling point in order to achieve job satisfaction and/or recognition (that's the way I understood them anyway).