It’s been said that the only people who tell the truth are the children and the insane. Now, developers may seem insane at times and they are just as prone to childish tantrums as anyone, but that doesn’t 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 you navigate the subtle inflections and sneaky barbs of your developers, here is a translation guide to some of the terms developers often use in team meetings.
‘Non-standard’
On a good day, standards are a nice way for a group to synchronize their behavior and build up a collective stack of code that encourages cooperation and tons of network effects. On a bad day, they’re 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” don’t 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 favorite toy by saying it’s the “new standard” or “it’s 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 don’t become standards without time. If something is “new” then it’s 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 won’t know whether the parade will fall into line without time.
That doesn’t mean developers don’t have good intentions when they tell you it’s a “new standard” that they’re 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’re 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’re usually speaking truthfully. Because they really hope it will be finished quickly. It’s just that there are all too many things that can go wrong with computers. Sometimes it’s the network. Sometimes it’s the legacy database. Sometimes it’s 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’s 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’re not talking about time any more. They’re just saying they don’t 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 realize 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’s hard to claim with a straight face that’s impossible. Better to bury it by claiming it’s infeasible or impractical.
This behavior is common in all layers of a bureaucracy, of course. It’s 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 don’t. 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, subnumbers 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’re actively fighting fire codes and zoning codes that may or may not protect customers, but they’re happy to insist on how many non-functional spaces are in their code stack. (See here and here.)
The problem isn’t that developers have opinions about how to write code; it’s 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’re 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 specializing 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 don’t 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’s best to concentrate on the happier aspects when developers speak of APIs, like when Frost himself concludes, “Good fences make good neighbors.”
‘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’s 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’re 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 begin with big dreams — and sometimes we manage to finish 50 percent of them. Choosing how much to bite off is not an easy task. If you’re too conservative, you don’t accomplish much. But If you try to go big, well, you’re 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’s 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’ve 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 don’t 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’re 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 don’t like the code and it’s often simply because the other team wrote it.
While any user understands the concept of a “bug,” it’s actually hard for programmers to recognize them. Code defines itself. Some developers say there’s no such thing as a bug; it’s just a matter of use cases that haven’t been written yet.
Don’t get sucked into their philosophical swamp. If the user can’t accomplish something, it needs to be fixed whether it’s 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’s a deep question about how much work the developers should do to make life simple for the folks who can’t 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.
ay, where
nt and their clients, will quickly start moving backward (and fast) in the new services market that’s emerging.
The LeanOutSourcing Blog 