Embracing My Inner Geek: Part 2 – The Job

Hi Slashdot, read this, woulda ya?

Did you ever see that one Friends episode where they make up a game where they test their knowledge of each other? In one of the rounds, the girls are asked what Chandler does for a living, and the answer they come up with is “transponster!” Which of course isn’t a word. All they know is that he carries a briefcase. Well I suspect that many of my friends don’t know what I do for a living. I suspect, if asked, you’d answer something like “I think he fixes computers.”

I know jobs aren’t the most interesting topic, but in my continuing series on embracing my inner geek, I think its important to tell you all (you who are interested anyway) what happens at my job. If you’re at all interested in who I am, you should know what I do. And believe it or not, I don’t fix computers for a living.

In fact most employers I’ve worked for actually have rules in place to suggest that I not try to fix my own computer. There’s these organizations, some (not all) still stuck in the 70s and 80s, called “I.T. Departments” who’s official purpose is to fix computers — but who’s actual purpose is to attempt to prevent their users from doing anything dangerous (read: useful.)

I do not, and have never, worked in an “I.T. department,” although I’ve volunteered those skills I have in that area on many occasions. In actuality, my job is much different.

I am, in the States, known as a Software Engineer. In Canada we’re not allowed to call ourselves engineers, although the discipline is no less rigorous than any other kind of engineering.
But perhaps its for the best, because “engineering” describes only a part of what I do.
A software developer must be part writer and poet, part salesperson and public speaker, part artist and designer, and always equal parts logic and empathy. The process of developing software differs from organization to organization. Some are more “shoot from the hip” style, others, like my current employer are much more careful and deliberate. In my 8 years of experience I’ve worked for 4 different companies, each with their own process. But out of all of them, I’ve found these stages to be universally applicable:

Dreaming and Shaping

Napkin SketchA piece of software starts, before any code is written, as an idea or as a problem to be solved. Its a constraint on a plant floor, a need for information, a better way to work, a way to communicate, or a way to play. It is always tied to a human being — their job, their entertainment… their needs. A good process will explore this driving factor well. In the project I’m wrapping up now I felt strongly, and my employer agreed with me, that to understand what we needed to do, we’d have to go to the customer and feel their pain. We’d have to watch them work so we could understand their constraints. And we’d have to explore the other solutions out there to the problem we were trying to solve.
Once you understand what you need to build, you still don’t begin building it. Like an architect or a designer, you start with a sketch, and you create a design. In software your design is expressed in documents and in diagrams. Its not uncommon for the design process to take longer than the coding process.

As a part of your design, you have to understand your tools. Imagine an author who, at the start of each book, needs to research every writing instrument on the market first. You have to become knowledgeable about the strengths and weaknesses of each tool out there, because your choice of instrument, as much as your design or skill as a programmer, can impact the success of your work.
Then you review. With marketing and with every subject matter expert and team member you can find who will have any advice to give. You meet and you discuss and you refine your design, your pre-conceptions, and even your selected tools until it passes the most intense scrutiny.

Once you have these things down, you have to be willing to give them up. You have to go back to the customer, or the originator of the problem, and sell them your solution. You put on a sales hat and you pitch what you’ve dreamt up… then wait with bated breath while they dissect your brain child. If you’ve understood them, and the problem, you’ll only need to make adjustments or adapt to information you didn’t previously have. Always you need to anticipate changes you didn’t plan for — they’ll come at you through-out the project.

Once you know how the solution is going to work, or sometimes even before then, you need to figure out how people are going to work with your solution. Software that can’t be understood can’t be used, so no matter how brilliant your design, if your interface isn’t elegant and beautiful and intuitive, your project is a failure.
Pointalist art: Sunday Afternoon By Seurat
I don’t pick those adjectives lightly either. All of them are required, in balance. If its not elegant, then its wasteful and you’ll likely need to find a new job. If its not beautiful, then no one will want to use it. And if its not intuitive, no one will be able to use it. The attention to detail required of a good interface developer is on par with that of a good painter. Every dot, every stroke, every color choice is significant.

To make something easy to use requires at least a basic understanding of human reactions, an awareness of cognitive norms. People react to your software, often on a very base level. If you don’t believe me, think of the last time your computer crashed before you had a chance to save the last 2 hours worth of an essay, or a game you were playing.

What you put before your users must be easy to look at so that they are comfortable learning it. It must anticipate their needs so that they don’t get frustrated. It must suggest its use, simply by being on the screen. And above all else, it must preserve their focus and their effort.

So you paint, using PowerPoint, or Visio, or some other tool, your picture of what you think the customer is going to want to use, and once again you don your sales hat and try to sell it to them. Only, unlike a salesperson selling someone else’s product, you are selling your own work, and are inevitably emotionally-attached to it. Still, you know criticism is good, because it makes the results better, so you force yourself to be logical about it. Then finally, when your solution is approved, and your interface is understood, you can move on to the really fun part of your job:

Prose and Poetry

A good sonnet isn’t only identified by the letters or words on the page, but by the cadence, the meter, the measure, the flow… a good piece of literature is beautiful because it is shaped carefully yet communicates eloquently.

Code is no different. The purpose of code is to express a solution. A project consists of small stanzas, called “Methods” or “Functions” depending on what language you use. Each of these verses must be constructed in such a way that it is efficient, tightly-crafted, and effective. And like a poem, there are rules that dictate how it should be shaped. There is beauty in a clever Function.

But the real beauty of code goes further than poetry. Because it re-uses itself. Maybe its more like music, where a particular measure is repeated later in the song, and through its familiarity, it adds to the shape of the whole piece. Functions are like that, in that they’re called throughout the software. Sometimes they repeat within themselves, in iterations, like the repeating patterns you see in nature.
Intricate FernAnd when the pieces are added up, each in itself a little work of art, they make, if programmed properly, a whole that is much more than a sum. Its is an intertwined, and constantly moving piece of art.

As programmers, we add things called “log messages” so that we can see these parts working together, because without this output, the flow of the data through the different rungs and branches we put together is so fluid that we can’t even observe it and, like trying to fathom the number of stars in the sky, it is difficult to even conceptualize visually the thousands of interactions a second that your code is causing. And we need to do this, because next comes a Quality Assurance Engineer (or QA) who tries to break your code, question your decisions, and generally force you to do better than what you thought was your best.

I truly believe that code is an art form. One that only a small portion of the population can appreciate. Sure anyone can walk into the Louvre and appreciate the end result of a Da Vinci or a Van Gogh, but only a true artist or student of art can really understand the intricacy of the work behind it.

Similarly, most people can recognize a good piece of software when they use it (certainly anyone can recognize a bad piece of software) but it takes a true artist, or at least an earnest student, to understand just how brilliant — or how wretched — the work behind it is.

And always, as you weave your code, you have to be prepared to change it, to re-use it, to re-contain it, to re-purpose it in ways that you can’t have planned for. Because that is the nature of your art form — always changing and advancing.

Publishing and Documenting

Its been said that a scientist or researcher must “publish or perish.” The same is true of a software developer. A brilliant piece of code, if not used, is lost. Within months it will become obsolete, or replaced, or usurped, and your efforts will become meaningless, save for the satisfaction of having solved a problem on your own.

So after months of wearing jeans, chugging caffeine, cluttering your desk with sketches and reference material, you clean yourself up, put on a nice pair of pants, comb your hair, and sell again. Although most organizations have a sales force and a marketing department, a savvy customer will invariably want technical details that a non-coder can’t supply. As a lead developer on a project, it falls to you to instill confidence, to speak articulately and passionately about the appropriateness and worth of your solution.

Again, as before, pride is a weakness here, because no matter how good you are, someone will always ask if your software can do something it can’t — users are never really satisfied. So you think back to the design process, you remind them when they had a part in the decisions, and you attempt to impress upon them respect for the solution you have now, while acknowledging that there will always be a version 2.0.

And you write and you teach. Not so much in my current job, but in one previous, as a lead developer it was my responsibility to educate people on the uses of our technology — to come up with ways to express the usefulness of a project without boring people with too many technical details.
One of the best parts of software development, a part that I miss since its not within my present job description, is getting up in front of people — once they’ve accepted your solution — and teaching them how to use it and apply it. Taking them beyond the basic functionality and showing them the tricks and shortcuts and advanced features that you programmed in, not because anyone asked you for them, but because you knew in your gut they should be there.

And Repeat…

Then there’s a party, a brief respite, where you celebrate your victory, congratulate those who’ve worked on parallel projects, and express your deepest gratitude for your peers who’ve lent their own particular area of expertise to your project… And you start again. Because like I’m sure any sports team feels, you are only as good as your latest victory.

So do I fix computers? Often its easier or more expedient to hack together a solution to a problem on my own — certainly the I.T. Department is becoming something of a slow-moving dinosaur in an age where computers aren’t the size of buildings, and most of us are comfortable re-installing Windows on our own — but that’s not a part of my job description.

No, I, like my peers, produce art. Functional, useful, but still beautiful, art. We are code poets, and it is our prose that builds the tools people use every day.
However, unlike most other artists, we’re usually paid pretty well for our work 😉

Post-script to Slashdotters (did you RTFA?!)

A few things to clarify here, based on the comments on the site:

  • The intent was not to gripe about Canada’s standards for the term “engineer.” I only pointed that out the difference between my home country, and my current country of employ. I prefer the term “software developer” myself, but it doesn’t really matter to me. It was only one sentence in a 2100+ word article — hardly my thesis!
  • The intent was also not to be pompous or fuel my own ego, it was to describe, as eloquently as I knew how, what most of us on Slashdot are. Although the stigma is going away, us geeky types tend to be considered only that: geeks. When really there is art and beauty to what we do. I’m not even as skilled a programmer as I imagine most are, but I wanted to lend my prose to our art because I believe it is valuable. But flame on, if you must! However, please note that I do have a degree, I work for a big company that prides itself in the quality of its products, I have 8 years of real experience, and I have a great life outside of work. This was a mental exercise, so please be nice!

I appreciate feedback — even critical, as long as its intelligent, so drop me a line if you have anything to say other than “you’re a douchebag” and “stop whining that you’re not an engineer.” But please do read the article first!

60 thoughts on “Embracing My Inner Geek: Part 2 – The Job

  1. I will never read or understand the code that you write. You were beyond me in that department by the time you were twelve. But if you write code anywhere near as beautifully as you write prose, it must indeed be a work of art.

  2. ‘Engineer’ in Canada is restricted because it requires you to have graduated from an engineering programme, per se. Some Universities’ “software engineering” programmes are under the engineering faculty and therefore qualify (i.e. Waterloo). Others, such as UToronto have “software engineering” in the computer science faculty which does not qualify.
    It has to do with the way the profession is regulated. “Engineering” degrees are accredited by a national panel and have certain specific requirements. CompSci departments can generally teach whatever they want.

  3. Hi, Jon!
    I just read your article and though that it was very well done. It explained beautifully the process of software design for those who have no clue as to what that entails.
    I’m Canadian and a Chartered Accountant by profession, and so can appreciate a logical, detailed and thorough approach to such a design; I suppose that many of my friends would consider me to be an anal obsessive-compulsive accountant, but I pride myself in taking a logical and professional approach to everything that I can.
    Thanks again for enlightening those out there who have no idea what goes into the process, and letting them know that you just don’t make great software by the seat of your pants.

  4. Thanks, Stephen (I hijacked this e-mail thread into comments so I’d have it recorded)! I really appreciate the thoughtful encouragement. My wife’s an accountant (although not Chartered), and although she’s a computer newb, I see a lot of parallels between her profession and mine. It definitely requires the same kind of logical problem-solving that software development employs!
    And thanks for setting the record straight, Engineer. I’m sure everyone at Slashdot is now properly educated on the use of the term, but this will add some clarification of the reasons for my other readers!

  5. Brilliant article Jon.
    Programming truly is an art form, no less then music, painting, writing… Those who cannot recognize or appreciate it as that simply do not understand it. It’s no surprise I keep reading articles about students graduating who don’t know how to implement a simple utility. It is the reason open source exists, and its the art behind programming that the Internet should be grateful.

  6. Eloquent if a bit unrealistic.
    We as developers are in fact the new blue collar class. You are only eight years into this; watch closely as our ability to express uniqueness; or as you position it artistic flair erodes with every new package that layers another level of abstraction from the developer and the underlying code.
    My revelation into this sad reality came back in the dot-com bubble when every secretary in the building was thrown onto a web project utilizing Cold Fusion. Suddenly they too were developers clicking madly away without a care in the world.
    I will say they provided enough entertainment over beers in discussing the finer points of their new careers to very nearly equal the destruction they wrought.

  7. And the main issue between Engineering in the US and in Canada, is that as a Software Engineer (in Canada, licensed through APEGGA) I am personally liable for my code and the code that I sign off on. If all the programmers in the US that flagrantly use the Engineer title had to be held personally responsibly for their code’s reliability lest they be fined, and lose their ability to ever practise in the field again — it would probably mean there are a) less people developing code; and b) that there would be a much higher baseline standard in the market, that is lacking in many operations.

  8. To ignorant engineer: if you had really gone to Waterloo, you’d also know that UW is most known for their Computer Science graduates from the math department, and NOT the engineering department proper.These are also very well qualified software designers, but in most cases cannot legally be called Professional Engineers, due to PEO restrictions. There are course options one can get to qualify, but most don’t, despite having taken largely the same math, programming and hardware courses. The REAL reason for PEO’s nastiness, is not to exclude degreed professionals, but to deny that title to those cookie cutter Microsoft MSCE and Cisco CNE “engineers”, hardly engineers at all. Pretty well every mom and pop shop, matchbook cover business school, Devry, community college etc. can train any monkey for those certificates.

  9. Thanks everyone, we can keep the flaming to Slashdot though. On my site, I’d prefer it if we could all just appreciate the beauty of a good piece of problem solving.
    I recognize that different places have different uses of the term “engineer,” and was actually quite surprised myself when my American employer classified me as such. But that’s not the point of this article — the point is that there’s as much beauty in a well articulated solution as there is to a well written verse or song. I’m sure most of you can point to a piece of work you’ve developed that you were proud of. That’s what we’re talking about here.
    Thanks for all the thoughtful feedback!

  10. The software developer as a frustrated artist has just become a little less frustrated! Your article is a breath of air for the stale perception of software development being a passionless endeavor.
    As the machine becomes more and more part of our lives it is this passion which will allow it to become more human both in usability and intent – and this is not a bad thing.
    Thank you for your expression.
    P.S. I trust the centre (oz) will always hold as such is it the basis currently for relativity, choice and ultimately experience. 😉

  11. Hey Jon,
    As a fellow Software Engineer it was great to read my own job/life description in such an elegant, concise article. I can’t say how many times I’ve thought about explaining that to someone only to fall back to “I’m a computer guy”.
    Keep up the artwork.

  12. I’m a software engineer. Three of my brothers are Professional Engineers (state licensed, degree from University, passed multi-day test, etc.). I took one of my brothers to a graduate Software Engineering class. He threatened to write the state board of licensing to say that nothing Software Engineers did was worthy of the term Engineer. He claimed it was an insult to the very word Engineer.
    I think he might even have had a point.

  13. I think the best part of being a s/w engg is the different that you can wear , its a very imp point that you brought out, it brings in a lot of dynamism . And if you happen to be in a place where you enjoy it, nothing can beat this.

  14. There you go !
    The code bug above is
    “I think the best part of being a s/w engg is the different *hats*”
    This was caught in UT before it became a customer bug !

  15. Nicely written article, but seriously — if you’re having to wear all of those hats, your company you’re working for is hosed. It’s also giving you a teeny bit of a complex — you’re sounding like the dot.bomb coders who thought they were more important than the business (or perhaps even having a business model). Coding is truly a mixture of some science, some art, and some other skills — but many of the soft skills you mention that you get forced into doing are just inefficiencies and screw-ups at your organization. Software “Engineer” is still an overstatement, many decades into this industry. Engineers design things to STANDARDS for safety, reliability, and then those designs are reviewed by 3rd parties OUTSIDE of the Engineering organization for whether or not they meet those standards. Probably only 10% of coders (if that many) work to that strict of a system, and regularly rebel against such a system if it were offered… they prefer to see themselves as Da Vinci or something, can-do, do-all, be-all men of thousands of talents — when their business managers would be wise to just get all of that crap off their backs and code to standards. We’re not even close to Software “Engineering” yet… when you have to be licensed to be a coder, I’ll believe it.

  16. A nice piece of writing. I teach between now and then some software engineering and other programming classes. I shall make sure I include this text in the reading list if you do not mind.
    If, however, there is one piece I would like to exclude is the bit about the IT department. You see I normally wear both hats, that of a programmer and also that of a sysadmin/IT manager. Obviously, I know nothing about the state of the IT departments at the place(s) you worked, but last time I checked with mine, we did not restrict developers…All right, we might place monitoring routines to make sure you don’t run services with admin privileges, but most of the time IT gets all the boring/complex tasks so that developers can do something useful. I am sure for instance, that most developers would be keen to focus on their API instead of tunning a large RDBMS and a multi tbyte file server, plug reliably a number of authentication back ends to 3 different OSes (Win, Linux, MACOSX – because let’s face it, you might launch your IDE in Windows, somebody else will like to do the same in Linux or MACOSX, but you all expect to mount your shares with the same username and password) even if they could do that. I am sure that they could setup VPN firewalls to work securely with the same authentication front end, but most of them prefer not to be concerned with that. You see, even if you acquired the skills to do all of these things, you would not do anything useful 🙂 .

  17. Great article. I think I will use these points when attempting my next pay rise – we are much more than just “coders”!!
    Many thanks

  18. I loved the article, and I thank you for it, because I intend to show it to people who have difficulty understanding our line of work
    You explained it all so thoroughly and so eloquently, that I do not need to add a word of my own 🙂

  19. Hi Jon,
    What’s absolutely hilarious is how involved people get in “naming conventions”. Engineer, software developer… who cares? I mean c’mon. It’s just a frigging title. Stop obsessing and start doing something useful instead.
    Jon, if every programmer were like you we’d have a much better software industry to begin with. What you write about the interface couldn’t be more true. Personally I find it strange that more people have not realized this. I struggle almost daily on combating “programmers” that insist on “knowing” what the best way is to design an interface… despite the fact they have not spent one minute with an actual client to understand their needs.
    Thanks for a well-written, articulate and informative article.

  20. A well-thought out and inspiring article. I think I’ll recommend that all my family members read your article so they might get a clue about what I do for a living!
    I’ve been a software developer for 10 years now and it’s recently been starting to lose its sheen … but a little reminder of the creativity that’s really involved brings back to me all the reasons why I got into it. It’s easy to lose sight of the fun parts of the job, but it’s also pretty easy to get them back into view.
    Now I think I’ll go & refactor something 🙂

  21. The State of Florida — or the state of confusion, depending on how you look at it — also wants to dictate what language individuals may use in labeling themselves. The Florida Board of Professional Engineers, through the Florida Engineers Management Corp, created by the Florida legislature to privatize offices under the Department of Business and Professional Regulation, wants to make sure you meet THEIR criteria for calling yourself an engineer of any kind in The State of Florida.
    Oh yeah … of course you have to pay your fees.
    My feeling is, if they only recognize credentials such as certification by the recognized institutions of supposed higher learning in this state, then I don’t want to call myself a software engineer anyway because it lowers MY standards.

  22. Well written. Sounds much like my current job, though I’ve never really found a good title for the job I do. My current job title is “Senior Engineer Advanced Test Development and Automation Systems” (and people wonder why I don’t wear my company ID around any more), though I have been called “Software Architect”, “Engineering Sales Manager” and “Project Engineer” in past jobs. I am actually a degreed Mechanical Engineer (though not a PE) and like Mechanical Engineering at heart, but happen to be able to talk to customers and be fairly good at software as well, and these latter traits seems to be much more in demand. So I get paid to deal with software-hardware interaction, and as your thesis discusses, this is as much a problem of gathering good use cases, understanding the needs of the end user and building consensus as actually being able to write good software. Mechatronics seems close to what I do (http://en.wikipedia.org/wiki/Mechatronics_engineering) but is not a popular term in North America. There is also Systems Engineer, though this typically doesn’t include software work.
    Good luck finding a title for yourself. The longer you are in the work force and the more areas you interact with, the harder you will find to classify yourself. And good luck describing that to your friends and family — I’m not sure my wife even knows what I do, and she is an engineer, too! Some days I envy people who can say “I’m a used car salesman” or “I’m an opera singer”, but then I look at the paycheck…

  23. Great !
    Recently, I have been taken myself during dinner, in a hard discussion about art in all kind of jobs.
    I must admit that I had a blank when my turn to talk about my job and art came.
    I think next time i would only quote you.
    Thanks !
    – A French IT student

  24. I have a few friends who are Software Engineers as you describe. Nowhere, in the years that I’ve known them have I seen such a beautiful, eloquent way of expressing just what it is they do. Thanks for helping a non-geek, who still likes to read /. to become a bit more geeky, help understand just what it is that software developers do. I marvel at the fact that in so many ways, you guys are the locomotive behind the wheels of what we use every day.
    Long live FLOSS (Free libre open source software)

  25. #+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    #|Even though I have been in IT after a life as Software Engineers(SE)….
    #|and I find your take on IT, a bit harsh…
    #|I still like your take on Software Engineering…
    #|Also, I have seen SE that compromise themselves with
    #|a job, just because they did not want to challenge themselves;
    #|Not all SE are created equal… so don’t put them all on a pedestal…
    #|I know a lot of them, and a lot are great people, but not all are good SE.
    #|Cheers, and keep on writing….

  26. This is my second career. I practiced law for 17 years before transitioning into IT, and have been in IT for about 15 years.
    I agree fully with your comments about art. My email tag is a quote by David Gelernter: “Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defence against complexity.” This is true about software and also law. You can read a legal code as a work of art, and if you want to try this, the UCC is a good place to start. I have read several codes this way, and you can apply the same literary concepts to legal codes as you can literature, theme, tone, development, etc. My language of choice is Perl, and you can certainly read code as literature.
    Something else to consider is that both law and SE are fields of applied logic. Law and SE may seem dissimilar, but they are essentially the same occupation, they just use different tools. In both cases, you have logical structures (legal code or programming code) that you have to apply to objective, real world data. You could write an essay similar to yours but emphasizing logic and reasoning skills.
    Writing software is an art, as is the practice of law, but it’s also a science, and in the case of engineering (requirements, design, testing, etc.) a very rigorous science. I think you need both sides to be successful.

  27. Charles,
    I’ve long been fascinated with the practice of law for those exact reasons. I don’t know that I posses the full skillset necessary to ever pursue it as a career, but I whole-heartedly agreed that both logic and creativity are required to be successful at it.
    I imagine these things apply to many other professions — ones that I might not understand well enough to respect as much as I should. I think the point is, the human mind is an incredible and expressive tool, and any time its properly applied, the result can be considered beautiful.

  28. Hello Jon,
    I believe that what you wrote describes very intimately what Software …..(put your own title) have to deal with.
    The way you describe the whole process is unbelievable!!!
    Thank you for giving a very good description of what I have to deal with every day

  29. “…tricks and shortcuts and advanced features that you programmed in, not because anyone asked you for them, but because you knew in your gut they should be there.”
    This is an extremely important facet of software development, and one that is being lost. Truly great software can never be completely described by specifications. The creativity, expertise, and subject knowledge of the developer is critical in making the difference between good and great software.
    Unfortunately this aspect is being lost as developers increasingly implement exactly what is in the specifications. Anyone who’s worked with overseas outsourced developers has experienced this. It’s also the trend for in-house programmers as managers try to turn individuals into a pool of interchangeable coding machines.

  30. Ignore the bitchers, they are a bunch of idiots with the attention span of gnats, unable to read past the first thing that triggers their eliza like brains into kneejerk reaction.
    Nice article. and yes, it DOES express nicely what we do, and how (many of us) think about it.
    And grats on your dads response, it is always nice to receive positive familial feedback.

  31. hi jon
    really impressive work!
    as i am a mechanichal student not knowing much about the industry and got a job in the softwares i found it very interesting and useful.i dont know the beauty of coding much but the way you described it is very beautiful

  32. Hello Jon,
    I am Charles Sutikno ,a software engineering student from Australia. I enjoy reading this article very much! I have never viewed writing code from this perspective before.
    It’s very refreshing and artistic especially with one of your paragraph (I copied them below),I can truly identify with !
    “I truly believe that code is an art form. One that only a small portion of the population can appreciate. Sure anyone can walk into the Louvre and appreciate the end result of a Davinci or a Van Gogh, but only a true artist or student of art can really understand the intricacy of the work behind it.
    Similarly, most people can recognize a good piece of software when they use it (certainly anyone can recognize a bad piece of software) but it takes a true artist, or at least an earnest student, to understand just how brilliant — or how wretched — the work behind it is.”
    Not only from this paragraph but you were able to portray the general life of a software engineer accurately. Developing software is not just merely coding as opposed to many misconceptions from many people.
    Software engineers are no conventional artist like Davinci but I have to say we are the artist of the modern world.

  33. I must say,
    I will be saving this article because NEVER has anyone so perfectly conveyed my feelings toward software development. You sir, are a true developer, something that is so rarely found. I know I have just completed my degree but long have I thought of it as a piece of art and an engineering discipline.
    Sadly here in my country (Trinidad & Tobago), people really don’t understand what the job requires and since the industry is small, with no union, developers aren’t paid that well.
    anyway Great Job!!

  34. Just to add what I’ve said earlier, I totally agree with you. A lot of my friends cant differentiate between IT and software engineers.
    Charles Sutikno

  35. Hi Jon, I have to say that I can completely relate to your post. You put it better than I could, so have passed a link on to all my friends so that hopefully they can understand what I do. Cheers.

  36. clear writing! i like it.
    i’ve been trying to find “embracing-my-inner-geek-part-1-the-job”. Where’s part 1?
    or is there a part 1?

  37. My husband is a Software engineer, and for years I was telling people that or “he writes code and makes websites” After years of him trying to explain it to me… I finally get it!” (I swear I am not an idiot, just a pediatrician who doesn’t have to deal with this stuff.)
    ps. If you ask my mom what her son-in-law does, she answers “i dunno, he clicks a mouse and fixes stuff.”

  38. Thanks for this wonderfully written piece. Many of the things you said really resonated within me.
    I have a question for you. How do you think someone who did not get a degree in CS or software engineering, eventually become a good software developer/engineer/architect without getting further formal education, and surpass those who did receive formal education? I know that if one truly wants to be successful in a particular field, one does not need to take classes in that field. But I just wanted to hear your take on this.
    Thanks in advance!

  39. Viv: I always like to think of this, from Proverbs 22:29
    29 Have you beheld a man skillful in his work? Before kings is where he will station himself; he will not station himself before commonplace men.
    If you are skillful in your work, people will notice. If you have that inner drive to always be better, and work hard at it, you will make it. But it has to be like a fire.
    Currently I have no BS in CS either, but I have finally worked my way up to the title of Software Engineer I. I started in Manufacturing!

  40. Viv:
    It think its because software engineering has more similarities than differences with other professions. Since what SE does is already written here you will see that some one with mathematical skills, logical reasoning ability, level of discipline required for engineering and passion can easily come in to software development.
    People doing most other jobs also have to have above skills and if they move in to software development all they got to learn is the technical side which is not that difficult.
    Also having a formal education in IT or not going to matter much after few years of leaving school or uni. Because this is a very fast changing industry so what matters most is keeping up with the changes in the field.
    I personally know lots of people that come to software development form other paths such as Law, Teaching, Medicine, Other engineering fields, And I also know few former software developers later became successfully in areas like Low, Teaching, and Music

  41. Beautiful article – thanks for writing it. You help an outsider understand the ‘terrible beauty’ involved in writing code and designing software. A healthy combination of anaylsis and intuition. Keep writing!

Leave a Reply

Your email address will not be published. Required fields are marked *