Real Programmer: n.
A particular sub-variety of hacker: one possessed of a flippant attitude toward complexity that is arrogant even when justified by experience. The archetypal Real Programmer likes to program on the bare metal and is very good at same, remembers the binary opcodes for every machine he has ever programmed, thinks that HLLs are sissy, and uses a debugger to edit his code because full-screen editors are for wimps. Real Programmers aren’t satisfied with code that hasn’t been tuned into a state of tenseness just short of rupture. Real Programmers never use comments or write documentation: “If it was hard to write”, says the Real Programmer, “it should be hard to understand.” Real Programmers can make machines do things that were never in their spec sheets; in fact, they are seldom really happy unless doing so. A Real Programmer’s code can awe with its fiendish brilliance, even as its crockishness appalls. Real Programmers live on junk food and coffee, hang line-printer art on their walls, and terrify the crap out of other programmers — because someday, somebody else might have to try to understand their code in order to change it. Their successors generally consider it a Good Thing that there aren’t many Real Programmers around any more. For a famous (and somewhat more positive) portrait of a Real Programmer, see The Story of Mel’ in Appendix A. The term itself was popularized by a letter to the editor in the July 1983 Datamation titled Real Programmers Don’t Use Pascal by Ed Post, still circulating on Usenet and Internet in on-line form.
The Story of Mel
Real Programmers write in FORTRAN.
Maybe they do now, in this decadent era of Lite beer, hand calculators, and “user-friendly” software but back in the Good Old Days, when the term “software” sounded funny and Real Computers were made out of drums and vacuum tubes, Real Programmers wrote in machine code. Not FORTRAN. Not RATFOR. Not, even, assembly language. Machine Code. Raw, unadorned, inscrutable hexadecimal numbers. Directly.
Lest a whole new generation of programmers grow up in ignorance of this glorious past, I feel duty-bound to describe, as best I can through the generation gap, how a Real Programmer wrote code. I’ll call him Mel, because that was his name.…
Why You Should Care About Your Software
My version of Ivan Jovanovic’s blog post on “Nobody Cares About Your Software”.
I work for a company where the delivery of media and news is its primary focus. We deliver that content through many different types of screens and in today’s modern world, almost all screens support a connection to the internet and even the ability to run software. Like many other media companies, to generate revenue we need to provide a valuable experience to our users so that they continue to consume our content.
This is different that many other companies that I have worked for where we sold software that brought value to the customer. At my current company, software is not sold but rather made available to the users for free; we sell what the software does. In this post I’d like to share with you some things that I have learned about how a company that sells what its software does should sees its own software.
Overgeneralization
Many of the decision makers in any organization are very concerned about the perceived value their software provides. This thinking is not wrong however, in some cases this thinking can cause over generalizations to be thrown around. As a result, engineers are forced from the top to cope with very large and broad scopes in short periods of time. What is missing from the decision making process iis the understanding of quality and value – the value that is achieved from the quality of the software affects how value is perceived. Even though, “nobody cares about your software”, every decision made on the software platform greatly induces the ways in which you are able to communicate messages to users.
It is not uncommon that people, when they want to say something, will say it in a generalized format. It is easier to share because getting into details needs explanations and can remove focus from the main point. Often this is enough to get a message across, but there are other cases when we can’t simplify more than the problem allows.
When should users and stakeholders have to care about our software?
At first, the answer to me was not inherently obvious because I have never asked myself this question. But after some thought, the answer was quite simple: when the software starts to get in their way. Let us run through an example.
You have a swiping gallery on your mobile website that allows users to swipe with their fingers from photo to photo. On most modern devices this works okay but on older devices the experience feels broken but still sort of works. The history of implementing this feature typically goes something like this.
● Product owner comes with a really great idea for a touch enabled photo gallery.
● Engineers explain that the current supported list of devices doesn’t support modern techniques of creating a feature like this.
● The engineers will make it work somehow.
This illustrates somewhat how the relation between the software and technical explanation of this problem directly affects the users. And from the users perspective they still don’t care that you can’t or don’t have the time to implement it properly.
Some questions like the ones below usually follow:
Why doesn’t it work the same on all devices?
We didn’t have time to properly implement an architecture that would support the various browser versions.
Why didn’t you have time to implement it properly?
We didn’t have any current model to start with and we had a deadline to meet.
Why didn’t you choose some open source project that had more features?
There really isn’t any good open source project target for mobile, nevermind all the mobile devices our users currently use.
Why didn’t you take your time for such an important decision?
Besides the many other things we have to do, we are short on resources and it was made clear that this feature had to go out in the next release.
This is beginning to sound more like a management issue where the general attitude is that “nobody cares about software” and only about bringing value. The issue is much worse when the same attitude is carried by the senior engineer managers that are directly connected to the development of software. So what do we do to change the process so that the user doesn’t have to care about the software?
Well, in my honest opinion producing software that the user doesn’t have to care about is what building a business that relies on software as a means of content delivery is all about. “Others should care that a user can fulfill his goal by using software and not caring about the software itself”. Below is a quote from Ivan Jovanovic and is a proposal on how we begin to solve this issue.
Management should care that service company provides is satisfying and that users are not leaving for the competition. They should as well care that software is maintainable with reasonable price because they pay that maintenance at the end, stable and reliable and that it produces more happy than unhappy uses, easy to understand and documented well so they can expand the team fast, people are educated for the position they do so they don’t introduce stupid things into the codebase, environment is optimized for long time work of this kind, motivation is high. Mostly non-technical things that make life of people that produce software confortable and make environment in which software is built stable and predictable.
Product owners should care that they can use software as the modeling tool for easy prototyping and trying out new ideas, that quality of the product is not restricted by the software fallacies, that software is not just visible implementation but as well statistics gathering tool through which they can develop business ideas and prove some theories they might have .
Engineers should do their best to learn and understand the software building and how to produce more quality, maintainability, flexibility and stability with the least effort involved and with fewest resources. We as engineers should as well really understand the domain we are working on and be aware of the environment in which we operate, company strategy and short and long terms goals. And lots of other things.
In addition, I would like to add that engineers should be passionate about what they are creating, continually learning more about their trade, wanting to implement best practices into their code, not to compromise quality and maintainability, and continually communicating engineering problems with colleagues to ensure proper knowledge transfer.
All of these are related to the state and health of the software. Politics and loyalties within the business aside, if we begin to care about the software we can provide software to the user without them having to.
An Open Letter to Recruiters And Their Clients
Recently, I participated in a logic test administered by a recruiting firm that primarily deals with high profile technology companies. Logical testing is a common practice in the hiring process of technology companies, and as a developer I’ve written such tests many times. For those of you who are unaware of what this practice entails, a logic test is made to evaluate an individual’s ability to logically deduct an answer from a set of arbitrary facts or statistics. Logical deduction is an important asset for any good developer and frankly, every developer should have it.
Anyway, I’d like to share, based on my own experiences, my thoughts on how these tests are evaluated with this latest test that I completed. I will begin by walking through the questions and answers but first a little background on the it. The rules of the test are that it be completed remotely in under an hour from the time it arrives in your inbox. In total there are four questions that need to be answered. I am not sure how many questions must be correct in order to pass but it is definitely more than one. Note: The company and afflilated recruiting agency will remain anonymous for obvious reasons.
Question 1:
Dr. Jones kept an antique clock in his office waiting room. One day after lunch he had only four patients. When he had returned from lunch the clock was still in the waiting room, but after the fourth patient left and Dr. Jones passed through the waiting room again, he noticed the clock was missing.
The police questioned the four afternoon patients, but they had gotten together and decided that every statement they would make would be a lie.
Adam said: None of us stole the clock. The clock was still there when I arrived.
Bert said: I arrived second. The clock was missing when I arrived.
Charlie said: I arrived third. The clock was still there when I left.
David said: The clock was missing when I arrived.
In what order did the patients arrive, and who stole Dr. Jones’ clock?
This is one of those long drawn out questions where you must pick up some key facts in the story in order to properly apply deductive reasoning and produce an appropriate answer. Actually, in this case there is one important fact to take notice of in the last statement, “…they had gotten together and decided that every statement they would make would be a lie.”. This statement implies the four patients are in collusion with each other, immediately making them all guilty of the crime and therefore the order in which they arrived is irrelevant. Even if I were to try to logically deduct an order of their arrival, logic tells me that it is impossible since they have plotted to provide confusing answers. As a computer scientist, when trying to solve a problem, if a set of conditions cannot be evaluated to a positive conclusion, one of two is true: there is a logical fallback or there is no solution at all. And since we know for certain that the patients collectively lied, we cannot determine the order of their arriva. We can only logically claim that it was a collaborative effort to steal Dr Jones’ clock.
When I asked for the answer to this question the answer I got was, “The only consistent solution has the order of arrival as Bert, David, Adam and Charlie. And David took the clock” This may very well be the truth if this was a real situation with real people but it is unclear to me how you can claim such a thing based on the facts of the story. If the tester wanted the following answer to be derived it would of been useful if the wording was less misleading. My problem however, is not the with answer itself but with the evaluator who in this case is the young female recruiter with little or no knowledge of the trade who rather than evaluating every answer independently and objectively, will instead simply follow the answer key. Not to mention this particular recruiter could not properly explain to me the job description.
Question 2:
You have 8 balls. One of them is defective (but not visible to the eye) and weighs less than others. You have a balance to measure balls against each other. In 2 weightings how do you find the defective one?
This was a tough one for me because I couldn’t come up with a solution in just two weightings. The best solution I could come up with was a recursive search algorithm based on splitting. In essence this would take four balls on each side of the balance and discard the heavier four, split and repeat. The result gave me three weightings in total which did not satisfy the question. When I asked for the answer I was told, “weigh 3x3 and weigh 1x1”. This is in fact correct since you can find the defect within the lighter batch of the 3x3 in the second weighting amongst the two that are weighted or the one that was not. It’s quite a nice solution actually. Practically speaking however, if I had to solve this problem with a piece of code it is unlikely that I would write a search algorhithim that always took an input of eight since the amount of steps to perform such an operation in code would take just as many as the split recursive method, if not more.
The third question in this test I will not go into. I cannot argue against in any way that I was not wrong in answering it but as a last ditch effort to save my pride, I did do the test during a lunch meeting. I did however get the fourth question correct!
In the end, my CV will never see the desk of the prospecting client thus blocking the potential opportunity for an interview. This was what was most upsetting to me. Not because I am looking for a job because I have a good job. I actually just enjoy going to interviews to see what kinds of possibilities are out there and to help better evaluate myself and my abilities. But for those people who are talented and really need the job, scenarios like these are truly unfortunate. My wish by making my thoughts public is that companies who are looking for talent should really investigate how their recruiters go about evaluating potential employees. It is both beneficial to the company and for the applicant if the experience were to be better. Companies would have more opportunities to hire good developers and developers would not feel so inadequate for failing an ambiguous logic test.
I wish I’d kept or remembered more tests questions that I’ve encountered to make my point more clear but I hope this will suffice for now. If, or shall I say when I come across these scenarios again I will definitely be updating this post.
I’ve often said that the only people who will truly appreciate someone’s art are other artists. Only they know how much work is put into something that another has created, because they’ve been through the process and know each and every conscious step.
Meanwhile, everyone else consumes it mindlessly, then regurgitates an opinion based on some uninformed value judgment without really thinking about what it is they’re criticizing, or without really caring about how much work and how much imagination must have went into making it.
Lot’s of people have been commenting the music & video Tak and I created a few years ago. So I thought I’d share it again.
Betanik Movement - Just Chillin’ (by Adrian Maurer)
Source: youtube.com
Eddie Obeng: Smart failure for a fast-changing world
Once in a while I come across a video on TED that is both inspiring and relative to the things I do everyday.
Away yeah. My name is on” indie games the movie” credits. (Taken with Instagram)
Faith in humanity restored.
Sometime on March 8th my bike was stolen from me in front of my office. I didn’t realize that it was gone until around 9pm when I left the office after a long day of work.
I don’t really know how to explain the feeling I had at that moment other than I felt an overwhelming feeling of helplessness. I’ve lost the bike I had so much history with and I probably wasn’t ever going to see that bike again. My only hope was that the thief would be dumb enough to post an ad on an online classifieds site. It was only a day that had passed by when I saw the ad, “stolen bike” on craigslist. The listing said…
“yesterday i stoped some crack head from stealing some ones bike only to find out two mins later he stole someone elses the bike he stole is a dark blue trek mountian bike when i saw this i grabed the bike and he ran off but rest asurred he got what was coming to him i got the cops found him and now hes in jail the cops at 14 division downtown have your bike go get it that and a u lock please cable locks dont work ”
I was in absolute shock. The description of the bike matched mine. I immediately called the 14th division office and confirmed that my bike was there. The next day I walked over to pick it up after work.
I just wanted to share that with everyone to illustrate that good things do happen and to restore a little more faith in humanity. Also, today I contacted the author of the ad and I am taking him out to lunch to thank him.
