Skip to content

Archive for


Appealing to Authority in Software Engineering

A great article I recommend reading for all programmers (and non-programmers alike) is Logical fallacies in software engineering by Artur Martsinkovyski.

A human brain is a complex machine that evolved over millennia. It works in the most peculiar ways possible and allows us to excel both at perception, dexterity and mind work. Some of its functions are a bit hacky. There are a lot of stereotypes and shortcuts that our mind takes in order to be more efficient and take less energy to fulfill the task. It helps most of the time although, being overwhelmingly erroneous at times, so that it leans you to the wrong decision, building an incorrect map of reality. The lenses of your perception may be flawed, the mechanism that grinds up the information you collect may be malfunctioning, your mapping can be highly incorrect.

Such errors have a name. This name is ‘fallacy’. A fallacy is reasoning that is evaluated as logically incorrect and that undermines the logical validity of the argument and permits its recognition as unsound.

Like other people of mind work, software engineers require a lot of thinking, analysis, and mapping of reality to fulfill their job. While doing these processes, our mind sometimes takes shorter routes to reach the destination, leading to wrong decisions or poor planning. To avoid that it is better to know your flaws.

He then proceeds to list the following fallacies:

  • Nirvana (perfect-solution)
  • Appeal to authority (argument from authority, argumentum ad verecundiam)
  • Historian’s fallacy
  • Misleading vividness
  • Survivorship bias

Let’s take a look at what I feel is the most common fallacy we as software engineers (or any professional, really) faces constantly: Appeal to authority.

[A]n assertion is deemed true because of the position or authority of the person asserting it. When explaining practices or opinions on some subjects of sofware development, project management, operations, e.t.c, people tend to use somebody elses saying, blogpost, conference talk or other claim as a foundation for justification of their own decision. Even though it might not always be fallacious, mostly it is better to add more contextual arguments that apply to specific solution or project rather than appealing to authority.

This can be a bit problematic when you have multiple people vying for a shred of authority in their role. I worked at a location once where everybody around me nitpicked every line of code I emitted because it didn’t follow their ideas. When challenged, they would fall back on either “This is the way he [architect] taught us to do it” or “This is a best practice” or the implied “I’m older than you and therefore smarter than you so you should bow down to me.”

I think programmers are now afraid of taking the risk of applying what they know and have experienced and instead are falling back on the results of others. Let’s say that you write a method that causes a memory leak. When you’re called out onto the carpet, you explain that the way in which you constructed the code was based on the directed opinion and approval of the project architect. Even though you noticed the potential for a leak, you ignored it because, hey, why should you doubt the architect? Isn’t s/he supposed to be the smartest person in the room? In turn, you get to be thrown under the bus while the authority that you yielded to denies all accusations.

At least with blogs, talks, and other tangible items, they can’t fight back.


Life of a Contractor (or, How I learned to be Treated like a Second Class Citizen)

I wish this was hyperbole.

I’ve had a few contracting gigs in my career as a software developer. Really, it is quite common in this industry. Many, if not a good majority, of contractors are not strictly 1099 workers per se (we’ll cover that in a minute); instead, many are employed by staffing agencies such as Robert Half and FGP and farmed out to clients who have an established contract. The employees typically submit hours worked at the client and, if approved, are paid through the agency. There is typically no benefits (or very poor benefits), no paid time off, and, because the you’re not in the “in” crowd of bona fide part-time and full-time employees wholly employed by the client, you may be looked down upon.

From the article Software Developer’s Guide to Contracting Versus Salary Employment by John Sonmez:

You can either be a contractor of some sort, or you can be a salaried employee. In my career, I’ve been both, and each has a distinct set of advantages and disadvantages. In fact, in some companies there is an entire culture built around the differences between contractors and employees. When I worked at HP, first as a contractor, then as an employee, there was this notion of “blue badgers” and “orange badgers.” Orange badgers were the contractors, and they were typically paid less, had no benefits, treated like second class citizens, and even at times told they couldn’t use the HP walkways or participate in any onsite activities. Blue badgers were HP employees who had a blue badge that signified their elite social status. They were employees and entitled to all the benefits contractors didn’t get. It was difficult to become a blue badger. Every contractor hoped to become one, but few did. But that is just one company culture. […] The reason why I am telling you this is that I don’t want you to be surprised if you feel like a bit of an outsider if you take a contracting job at a large company. While there’s nothing wrong with being a contractor, it’s also important be aware that you may not be included in the company culture.

As a developer, I can only attest to what my experience was like from the programming perspective. As a contractor developer, it was not uncommon for me to…

  • Have what considerable experience I had developing ignored. I’m all for having a uniform code base, but it does not require you talking to me like I’m a complete idiot or am so wet behind the ears that my nickname is “Niagara.” I can respect that as a contractor, my contributions could have a lasting impact–both negative and positive–and that, after my tenure, it would be up to someone else to maintain it. (Read this article for some more anecdotes about being a “highly paid consultant”).
  • Be regarded as the lowest rung in the caste system.
  • Have items kicked back from QA/other programmers because it didn’t meet whatever imaginary standard they had.
    • I should mention that as a trick, if you want to generate some plausibility into why you want to nerf a programmer, have QA keep sending back bugs that have been solved and demonstrated fixed. Do this enough times until you have a good percentage, then you can drop the hammer.
  • Be excluded from company events (which was fine; I wouldn’t expect my HVAC guy to join my family picnic).
  • Be accosted verbally. This seems to be a running theme in my life…

Contractors make up a large segment of many organizations. For example, Google essentially runs off contractors, the “invisible workforce, off company payrolls” doing grunt work “for the Silicon Valley giants with few rewards.” Indeed, “[p]eople look down on you even though you’re doing the same work” is the sentiment for many contractors not just for FANG but throughout the industry. The federal government lives and breathes contractors (helps avoid public unions).

I coped with these behaviors the best I could, often just riding them out until the next full time endeavor came along. There were times when it was awfully frustrating to be treated with such little regard. I hate being a contractor; it’s simply not my cup of tea. But, my father always told me: “Put up, or shut up.”

So, I shut up, was shown the door after the company merged with another, and landed a full time position in a job I love. If employees are seen as expendable, then contractors are seen as little more than a means to an end.

To employers, please: I know there are a lot of morons that get past the door, but there are plenty of good contractors who are great at what they do. They are a guest in your house, so try to make them at least feel a little bit welcome while they perform their duty.


The Games We Play: Hiring Senior Developers

Today I found myself reading the article Senior Developers are Getting Rejected for Jobs by Glen McCallum. I’ll let the opening paragraphs set the tone:

Being a software engineer isn’t easy by any means and oftentimes we (developers) find ourselves traversing through a Dragon’s Layer-esque of quizzes, tests, and the dreaded whiteboarding sessions. Granted, for a more junior-level position, I can understand a good whiteboarding session or some assessments to gauge whether or not the individual learned anything. But when interviewing someone who has years of industry experience, are these miniature gauntlets really helping anybody?

I think part of the problem is the fear of feeling “stuck” with a bad developer. From the article 7 Reasons Why Software Develoment Is So Hard by Paul Smyth, the author cites that “[t]here is no barrier to entry into the programming world and thus it is awash with many poor programmers who adversely affect projects.” Are we at the point where the industry demands perfection in every aspect of operations?

Or is it just practicality?

Continuing on from Glen McCallum’s blog, we see that while developers hate them, companies love them:

Programming puzzles as a hiring gate solve [the problem of a large quantity of applicants and weed out inexperienced applicants]. To a company it is worth skipping over a few great candidates in order to simplify the review and selection process. With a now unlimited pool of applicants they can afford to do that. The numbers suggest that there will always be more good developers in the pipeline.

For this reason I believe that Programming challenge hiring gates are here to stay and will become even more common in the future.

I have bad news for senior developers in the field: many job placement agencies (Robert Half, especially) implement these gates as well. And, as much as I hate them, my workplace utilizes these aptitude tests as we were wasting so much time interviewing poor candidates that couldn’t even tell me what an interface was.

Later we’ll talk about one aspect that exasperated this problem: coding boot camps and the games that they play. Until then, you better know damn well how to use the Strategy pattern in conjunction with a SQL query that can determine the vowel count of every last name in a Japanese customer database and every database has a different collation.


Data Centers: Huge Economic Impact for Who?

I was reading the article Why data centers fail to bring new jobs to small towns by Alison DeNisco Rayome.


In Boydton, VA, recently profiled in the New York Times, Microsoft recently built a large data center housing thousands of computer servers.

People thought when Microsoft came in it would create jobs, but that’s just not the case,” said E.W. Gregory, the head of the local International Brotherhood of Electrical Workers union. Instead, they brought in outside technicians to do most of the work, he added. About 25 local residents got jobs, primarily as administrative assistants or janitorial staff, Gregory said.

Hundreds of Boydton residents lost jobs in recent years, as several factories and a prison closed. Gregory said he believes Microsoft chose the town for a data center primarily because “land was cheap.”

It helps the community to a point, because restaurants, gas stations, and hotels are getting more business,” Gregory said. “The people are nice and hard working, but there is no industry for them to work in.


This is a subject that I can relate to as I’m from the area where Facebook plopped down a data center outside the rural town of Forest City, North Carolina. The chatter from elected officials and Facebook themselves was that this would be a boon for the local economy and create numerous new jobs. But, while the temporary outsourcing of local construction laborers was a small uptick, the same problem that was experienced by E. W. Gregory appeared. Data centers are, more or less, gigantic network closets. There is simply no need for that many technical staff. In any case, Facebook continued expansion projects, with the latest being as recent as 2016. An estimated “125 full-time jobs [and] full-time third party (sic) contractor positions” would be created. This is in a county with a population of around 65,000 with a workforce of roughly 26,000 people. Therefore, the presence of Facebook will theoretically have a 0.004% positive impact on a county that is already below the poverty line. Data USA states that the 2017 median household income was $38,573 (USD), which is $19,079 (USD) less than the median income of the country as a whole. The outlier in this instance is the Lake Lure area, which comprises the western half of the county (see below). Forest City (and my subsequent hometown of Ellenboro) is center and right.

Income by Location (Rutherford County, NC)

What an impact that data center is having, huh? When examining the most common and most specialized jobs, there was no change in the years since the data center’s operation:


I should also mention that Walmart is the biggest employer in the county. So why did Facebook choose Rutherford County and why did the county commissioners (and Duke Energy) bend over backwards to give them so much economic incentive? The answer is always the same: taxes. From the article Study: Facebook Data Center in North Carolina Has Massive Economic Impact, we see that $198,000 were added to local property tax rolls and $336,000 tax was paid on electricity usage (the state managed to get $194,000 in franchise taxes). The article goes on to boast that “[o]ver three years (since the site went live in April 2012) the data center resulted in addition of 4,700 across North Carolina, including direct creation of 2,600 jobs.”

Am I mad that Facebook built a data center in my former back yard? Hardly. I don’t live there and they are free to purchase land and set up shop wherever they want. What does irritate me is when they (in conjunction with the local government) start blowing smoke up the collective asses of the local populace. Of course, this is the same populace who keeps voting in the aforementioned local government, but what do I know? Apparently what’s good for the county’s (and state’s) goose is good for the gander.

So the next time someone suggests to you that a new data center is going to turn the town on its head and make waves, take it with a grain of salt.

Better yet, smack them with a car battery.


Is tech that’s deemed “obsolete” by outsiders “broken”?

The other day I was reading the post IT runs on Java 8 by Vicki Boykis. From the post:


In today’s online economy where thousands of developers are online, the person whose voice is the loudest gets the most weight. The loudest people aren’t going to be those working with legacy systems. (Unless you’re doing something extremely new).

This piece of the puzzle is the one that worries me the most. What I’m worried about is that places like Hacker News, r/programming, the tech press, and conferences expose us to a number of tech-forward biases about our industry that are overenthusiastic about the promises of new technology without talking about tradeoffs. That the loudest voices get the most credibility, and, that, as a result, we are listening to complicated set-ups and overengineering systems of distributed networking and queues and serverless and microservices and machine learning platforms that our companies don’t need, and that most other developers that pick up our work can’t relate to, or can even work with.

I’ve spoken and written about it at length, but, most times, easier is best.

And, if the tech is, in fact old and outdated, and the tradeoff from replacing it is lower than the tradeoff of keeping it, we shouldn’t be jumping to replace it with the latest and greatest. While we should evaluate new tools evenhandedly, most times, Postgres works just fine.

For better or worse, the world still runs on Excel, Java 8, and Sharepoint, and I think it’s important for us as technology professionals to remember and be empathetic of that.


In a sense, it really spoke to me. I have spent countless hours in situations where the current environment were “handcuffed” as it were to tech that had, at the surface, seemed like it had lived past its prime.

Or had it?

Many instances–public sector especially–are not by any means cutting edge. The utility sector, for instance, in many instances utilizes a de facto serial standard since 1979 that is (by itself) highly succeptible to man-in-the-middle attacks and is very limited in what data it can hold. Other cases it’s a matter of needing to get something out the door as fast as possible. One of my contracts involved an organization that needed an in-house web-based ERP yesterday. (They already utilized an ERP system from Infor that ran on an AS/400 but it was unable to effectively meet the requirements of the vendors for product listing and RPG IV programmers cost a buttload).

And they tasked two guys to do it. The result was a mishmash of ColdFusion (UX layer) and ASP.NET (service layer). This was 2015.

If you are a web developer or programmer, you can already feel the nausea. If you’re not, then understand that this was the equivalent of building Frankenstein’s monster from IKEA using parts you ordered off eBay.

But: it worked. To the best of its ability, it managed to get the job done. Yes, there were a lot of innefficiency in some of the operations that took place, but it got the job done, which to the company was “Good enough.” The skeleton team grew by six people and, from what I hear, is still chugging along with backlog of features that may never be toppled, but that’s a story for another day.

In his article IT’s Famous Last Words: If It Ain’t Broke, Don’t Fix It, Peter Waterhouse states:


In IT, we’ve become accustomed to managing services the same way. We keep our heads down and our systems running, prevent outages, and implement new applications. In business, our competitors play the same game, so we pay close attention to making sure our services perform at optimal levels.

This is, and always will be, important. But with the digital revolution, just running an IT shop better than anyone else doesn’t guarantee anything. Rather, success will depend on how quickly you market your offerings, how you structure your IT services, and especially how well you understand the pivotal role IT plays when it comes to remodeling your business.

To draw a parallel from the cut-throat world of retail fashion, clothing and accessory store Zara has become a huge success by developing a disruptive new strategy — and not because they have better stores than their competitors. They looked at what many in their industry regarded as the “not broken” element — slow time to market from initial garment design to shop floor (the tangled cables, if you like), and fixed it with a unique approach (unified design and manufacturing). Similarly, Netflix devastated the home video market, not because their employees worked harder than video store employees, but because they challenged traditional thinking — thinking that wasn’t really broken, just out of step with the move to digital content consumption.


Running an outdated IT strategy and managing the status quo is a recipe for disaster. The alternative is to work with the business to continuously review existing business models, re-examine cost structures and reduce operational debt to the point where IT is able to deliver the types of new applications and services that customers want.

Of course, none of this is easy if the entire organization is entrenched in the “not broken, don’t fix it” mindset. But fortune favors the bold who challenge traditional thinking.


So the next time you hear the cringe-worthy phrase “If it ain’t broke, don’t fix it,” stop and think. […] Always remember, it’s the “not broken” things in business that provide the best opportunities for innovation.


Maybe chasing after the “latest in greatest” isn’t the answer to remaining ahead of the curve in information technology, at least all the time. One should always evaluate their toolset and make adaptations as necessary in order to fulfill the needs of their customers. Last I checked there is still a need for C programmers.

In the public sector where availability of service, not competition, is the biggest worry, it is prudent to not disrupt the flow of what is provided to the citizens. We still see a lot of “obsolete” tech that still functions being utilized, especially in terms of the hardware that supports the legacy applications. An example is from the article DoD is migrating to Windows 10 and it will probably stick around forever by Kelsey D. Atherton:



Even after the (April 8, 2014) deadline, the Department of Defense continued to order support for Windows XP, with the Navy purchasing more XP support well into 2016, a year after the switchover to WIndows 10 was announced.

Invariably, the computers running pre-Windows 10 operating systems will dwindle, and the switchover will proceed to a satisfactory degree of accomplishment, even among the holdovers. But I wouldn’t expect older system to die entirely, and whenever the Pentagon switches to the post-10 operating system, expect to see Windows 10 kicking around on backwater computers. After all, this is the same Pentagon that still operates Windows 3.1.


Ensuring compatibility of these legacy apps is critical, so specialy care must be taken to ensure that they can be brought gently into the twenty first century.

So in answer to the question on whether “obsolete” tech is “broken”, the answer is: it depends.