It has been said that the only people who tell the truth are the children and the insane. Now, developers may seem insane at times and just as prone to childish tantrums as anyone, but that does not mean they speak the truth. Indeed, they often shade the truth just like the suits in the corner office when speaking to the developer team — they just use a different language.
To help navigate the subtle inflections and sneaky barbs of developers, here is a translation guide to some of the terms developers often use in team meetings.
“When developers say a feature or fix will be easy, they are usually speaking truthfully. Because they really hope it will be finished quickly. It is just that there are all too many things that can go wrong with computers”
‘Non-standard’
On a good day, standards are a nice way for a group to synchronise their behaviour and build up a collective stack of code that encourages cooperation and tons of network effects. On a bad day, they are a cudgel by which one tribe of developers beats down another.
Outside of a few corners controlled by government agencies, most so-called standards are just regular code with the word “standard” in the title. Some folks announced a “standard” and asked others to join. The real test is whether anyone follows the “standard” — and whether the industry alliances that uphold the “standard” shift as quickly as mall rats to new fashions.
When developers call a work initiative or chosen tool “non-standard,” they may be speaking truth. It would be silly, for instance, to forgo the established code built around HTML for some new layout scheme, no matter how good it is. But most so-called “standards” do not have the same kind of inertia as HTML, and so you have to poke a bit to see whether your developers are really just saying, “Not my cup of tea”, “not invented here”, or even “we hate this guy.”
‘New standard’
Developers love to tout their new favourite toy by saying it is the “new standard” or “it is quickly becoming the new standard.” Again, “standard” becomes a touchstone that’s meant to make everyone feel good about the choice.
The word “new,” however, should raise the hair on the back of your neck. Standards do not become standards without time. If something is “new” then it is too early to know whether the crowds will gather behind the bandwagon or your company will be one of the few left out to dry. Developers of the “new standard” may be blowing all the right horns and lighting lots of fireworks, but we will not know whether the parade will fall into line without time.
That does not mean developers do not have good intentions when they tell you it is a “new standard” that they are hot to adopt. After all, this often means they are interested in abandoning or deprecating some old approach. Perhaps they’ve pulled their hair out one too many times with how you’ve been doing things, and they are hoping this new approach or tool may actually solve some of the problems that have arisen. But you still have to be somewhat cautious of the new when invoked by developers.
‘One week’
Hope springs eternal. When developers say a feature or fix will be easy, they are usually speaking truthfully. Because they really hope it will be finished quickly. It is just that there are all too many things that can go wrong with computers. Sometimes it is the network. Sometimes it is the legacy database. Sometimes it is just foolish optimism. In any case, more often than not, “one week” really means “one month.” Or maybe even “six weeks.”
‘One month’
This is a more standard unit of estimation that you will hear from developers, and like “one week,” it is completely inaccurate as far as reality goes. The level of misestimating is probably similar as it is for “one week,” and it is not uncommon to see “one month” tasks expand by a factor of four to six.
‘One year’
When developers say something will take a year, they are not talking about time any more. They are just saying they do not want to do it. Maybe it will require learning or relearning to program in some language they didn’t like. Maybe it will mean negotiating with some team in another division, one that stole all the resources and maybe beat them in softball.
They would try the gambit of claiming it can’t be done but they often realise this is a losing ploy. Nine times out of ten, a competitor is doing just what you’ve asked your developers to do, so it is hard to claim with a straight face that’s impossible. Better to bury it by claiming it is infeasible or impractical.
This behaviour is common in all layers of a bureaucracy, of course. It is just programmers live in mysterious world inscrutable to outsiders. That makes it easier for them to play the game and then hide behind some odd standard or weird software layer you’ve never heard of.
‘Style’
Someone once said there’s no debating style — you either have it or you do not. Developers aren’t any different. They have opinions about the most attractive way to write code just as clothes designers care about tie width or skirt length.
Perhaps the most famous version of stylistic fascism is the AirBnB Style Guide for Node.JS, which include rules like one insisting putting a space both before and after a plus sign, rule 19.4. Rule 19.10 also forbids putting a space inside a square bracket while 19.11 insists on a space inside curly brackets. Yes, the rules have numbers, sub-numbers and embedded anchor tags so you can send a nastygram to some developer with misplaced spaces explaining exactly which “code style” has been violated.
AirBnB as a company may have a more relaxed view about regulations because they are actively fighting fire codes and zoning codes that may or may not protect customers, but they are happy to insist on how many non-functional spaces are in their code stack.
The problem is not that developers have opinions about how to write code; it is when they try to force others to bend to their will. Many developer tribes like to go to war over “code style,” which can often just be a passive-aggressive burn in a memo about “non-standard” issues. That team’s style is bad. Ours is good. For the most part, when a developer references “code style,” whatever they say next can be safely ignored. If there was a real technical issue around, say, interoperability, “style” wouldn’t enter the conversation. If your developers are stuck objecting to code style, consider it a pretty clear sign they are just being obnoxious.
‘DevOps’
The name sounds like a combination of “developer” and “operations,” but it really refers to the process of keeping the code running and the servers humming, a process complex enough for some around the office to start specialising in these chores.
But you can often detect a slight sneer in the voice of a programmer who delegates things to the “DevOps” team in the same way a great chef lets someone else worry about setting the table. Programmers think great thoughts about data structures and leave the job of keeping it running to others, regardless of what you would like them to do. In a way, “DevOps” can seem like anything developers do not want to do but needs to be done.
‘API’
Robert Frost may not have been a programmer, but he understood APIs when he wrote, “Something there is that doesn’t love a wall.” Programmers love APIs because they establish clear boundaries with rules for crossing them. By encapsulating the work, APIs allow those outside the API wall to avoid thinking too much about what is going on inside.
But when programmers say “API,” what they are talking about more often than not is control. The team that builds the API gets to set the rules, facilitating complaints about other developers who are using “non-standard” means to abuse the API. They can set up terms of service and rules of access, which no doubt others will want further opened up and arguments will ensue. Perhaps it is best to concentrate on the happier aspects when developers speak of APIs, like when Frost himself concludes, “Good fences make good neighbours.”
‘Better suited’ / ‘The right tool for the job’
Developers spend a lot of time learning the idiosyncrasies of a programming language and its supporting codebase. After all, the more they learn, the more efficient and valuable they become. So, it is no surprise that they often advocate for what they know best.
When they say that X or Y is “better suited” to the task, they are often just validating a choice they made long ago to dive deeply into one particular stack. The best approach is just to nod, smile and agree. The differences aren’t worth arguing about. After all, modern languages are relatively equivalent in power and capability, with most differences being largely cosmetic. Python programmers, for instance, are often proud that their language breaks up code into blocks using indentation instead of curly brackets. That may not be enough to pivot to Python with your next programming project.
‘Scope creep’
Projects being with big dreams — and sometimes we manage to finish 50% of them. Choosing how much to bite off is not an easy task. If you are too conservative, you do not accomplish much. But If you try to go big, well, you are much more likely to crash and get nothing done.
The phrase “scope creep” officially describes the process by which a once feasible goal is made impossible by adding all of these extra goals along the way. It is often mentioned defensively when developers try to stop a manager from adding another neat idea to the mix. Does it work? Sometimes but managers often counter with phrases like “raising the bar” or even worse, “Do it, or you’re fired.”
‘Cultural fit’
If you have ever thought humans have evolved beyond warring tribes, just watch developers use the words “cultural fit,” which are almost always a replacement for “person just like me.” Some see it used to exclude races and genders, but others see it deployed when discussing programming languages, APIs, and many technical items. People have their comfort zone where everything is just how they like it and those outside that comfort zone do not have a “cultural fit.”
‘Refactoring’
If a programmer called it “fixing mistakes” or “rebuilding things the right way,” it would sound like they were admitting incompetence. But somehow the word “refactoring” sounds scientific and even noble. Is it any wonder that programmers deploy it when they are cleaning up prior mistakes?
‘Feature’ vs. ’bug’
If a programmer says “feature,” it means they like the code, often because they wrote it. If they use the word “bug,” they do not like the code and it is often simply because the other team wrote it.
While any user understands the concept of a “bug,” it is actually hard for programmers to recognise them. Code defines itself. Some developers say there’s no such thing as a bug; it is just a matter of use cases that haven’t been written yet.
Do not get sucked into their philosophical swamp. If the user cannot accomplish something, it needs to be fixed whether it is called a bug or a feature.
‘Kludge’
A kludge is just an old slang for a stop-gap measure that’s implemented because there wasn’t time to do things “the right way.” The programmers will probably want to refactor by adding more code. In the future, the next team will refer to this refactoring as a kludge and the cycle will continue.
‘Luser’
The tech community has pretty much banished the attitude that only the high priest caste can work these machines and we should bother worrying about the rest of the world, the so called “lusers”. When the success of a tech platform is measured by the number of noses using it, the programmers get the message.
Still, there is a deep question about how much work the developers should do to make life simple for the folks who cannot begin to understand the tech. Just how much programmer time is worth spending to attract how many more incompetent dolts. Is it worth it? That’s a tough job for the management. If it were left up to the users, every field would take JSON data structures filled with regular expressions.
IDG News Service
Subscribers 0
Fans 0
Followers 0
Followers