What Are the Most Common Lies Told by Programmers?
Unveiling the truth behind the screens, we’ve compiled insights from CEOs and Founders to shed light on the most common fibs in the programming world. From the often misrepresented task feasibility to the classic “temporary” solutions, discover the candid confessions and professional experiences in these eleven revelations about programmers’ most frequent untruths.
- Misrepresenting Task Feasibility
- Underestimating Project Timelines
- Overstating Their Capabilities
- Misleading Ease of Learning Development
- Overconfidence in Code Perfection
- Exaggerating Busyness
- Misusing the “Clean Code” Term
- Denying Previous Code Functionality
- Misjudging Development Deadlines
- Calling Solutions “Temporary”
- Overreaching Design Skills
Misrepresenting Task Feasibility
Programmers make claims such as “This can’t be done”, or “I can’t do this”. As a programmer myself, before shifting gears into entrepreneurship, these come out a lot when a programmer thinks that the thing being requested is a terrible idea, and that the easiest way to get an annoying stakeholder, who doesn’t know the ins and outs of the business, to back off with little fuss.
Usually, this just means the thing would take too much time and effort, and be an overall pain to manage, and is therefore not worth the time for the programmer.
Dragos Badea, CEO, Yarooms
Underestimating Project Timelines
I don’t like to accuse people of lying, but the most common falsehood conveyed by programmers is that a project will take far less time than it ends up taking. My rule of thumb is to multiply the timeline that a developer gives me by three, to get closer to the actual time it will take to deliver a usable product.
There are almost always delays, miscommunications, and unexpected snags that cause delays in delivery. To get around this, consider an agile approach to development. Your minimum viable product (MVP) should be exactly that. Make your product as lean as possible, work with the programmers to deliver it, and then make improvements in the next iteration.
Dennis Consorte, Digital Marketing and Leadership Consultant for Startups, Snackable Solutions
Overstating Their Capabilities
I’ve observed that the most common lie programmers tell is when someone asks, “Can you do this?” and the response is a confident “Yes.” But, I don’t think it’s always intentional. It’s more often a byproduct of the tech world’s trial-and-error ethos. As an entrepreneur, I get it—the desire to tackle any challenge head-on and figure it out along the way.
Personally, admitting you’re not sure isn’t exactly a confidence booster, but in the startup realm, it’s vital to navigate uncertainties. When a programmer says “Yes,” it’s not always a guarantee they’ve got it all figured out; it’s more like they’re ready to learn, tackle the task, and complete it.
Johannes Larsson, Founder and CEO, JohannesLarsson.com
Misleading Ease of Learning Development
One lie is that anyone can learn software development and get a job. When I started teaching myself software development, everyone on YouTube told me it was quite easy.
However, there were countless nights when I considered quitting, and there was even a two-month period where I stopped teaching myself because it was so frustrating.
Constantly writing code only for it to break and having to go to Stack Overflow for help isn’t for everyone. Most people shouldn’t learn to program unless they have a genuine passion for it and aren’t doing it just for the money.
Scott Lieberman, Owner, Touchdown Money
Overconfidence in Code Perfection
The most common lie told by programmers is that their code works perfectly. This can sometimes be due to overestimating one’s abilities or simply wanting to be perceived as infallible.
An uncommon form of this, however, could manifest in an over-reliance on third-party code libraries; while these libraries are typically tested before release, there may still exist hidden bugs because of unforeseen parameters and interactions with other pieces of code.
Thus, even when being honest about individual contributions, a programmer may inadvertently express misrepresentation in the downstream functionality of their work.
Michael Alexis, CEO, Virtual Team Building
Exaggerating Busyness
“I’m busy.” This is something of a joke, but one with a kernel of truth to it. Most people not familiar with programming will see that a lot of programmers might hang around and are not actively doing anything. This does not, of course, mean that the programmer is idle.
They might be thinking about something to do with their project, taking time to de-stress to help their overall workflow, or just taking time during the day because they work an atypical schedule.
Explaining all this to a non-technical person, naturally, becomes extremely annoying the 100th or so time they have to explain it, you just end up with a general blanket statement of “I’m busy” when asked what they’re doing or if they are available to help with something. They might not seem actively busy, but they are.
Kate Kandefer, CEO, SEOwind
Misusing the “Clean Code” Term
What is defined as “clean code” is very subjective, and many programmers will use this term to make the client feel more comfortable about the work.
Most code, once reviewed by an experienced and well-respected programmer, will be deemed clunky and complicated, which slows down speed and weakens stability.
Ask for a better definition than “clean” for the work they will do and don’t hesitate to get a second opinion.
Jason Vaught, Director of Content, SmashBrand
Denying Previous Code Functionality
Coming from experience, I can say that most programmers have at least once mentioned the lie, “It was working before.” In reality, it often wasn’t. There’s a good chance that part of the code wasn’t properly tested.
The hope is usually that bugs won’t surface during cross-team meetings. However, when they do, it becomes obvious. I remember encountering this situation with one of our software developers. We were all puzzled, wondering why such a simple error wasn’t caught earlier.
It’s surprising and somewhat disappointing to realize that the code wasn’t thoroughly tested. Programmers might resort to this statement often because it’s a quick way to deflect immediate scrutiny and buy some time to identify and fix the issue.
It’s a sort of knee-jerk reaction to avoid immediate blame or to cover up a lapse in the testing process. I think they just say this lie because it serves as a temporary shield, easing the pressure at the moment while they scramble to resolve the problem.
Precious Abacan, Marketing Director, Softlist
Misjudging Development Deadlines
99% of them lie about deadlines. Well, they don’t proactively lie, but usually, they are just wrong in their assumptions. They fail to take into account many nuances that tend to emerge during the development process.
Notably, even very experienced developers who have been working in this field for over 15 years make such mistakes. That is why a project manager must calculate an index, different for each developer, that is used to multiply the time evaluation they provide, depending on the complexity of a task. For some, this index is 1.5, and for others, it is 5.
Daria Erina, Managing Director, Linked Helper
Calling Solutions “Temporary”
As an ex-software developer, I can tell you one classic line you often hear in meetings: “It’s just a temporary solution.” This has to be one of the most common, and perhaps optimistic, lies we tell ourselves in the programming world. We often use this phrase when we put together a quick fix or a patch, intending to come back and refine it later.
In reality, you will most likely be pushed by upper management to develop something else super urgent, and then the next thing. More often than not, these “temporary” solutions end up living much longer than intended. They become part of the codebase, comfortably settling in for the long haul and bringing trouble to the next ‘generations’ of developers who join the project years later.
It’s a bit of a running joke in the industry because every programmer knows that “temporary” in the tech world is hardly ever that. Sometimes, you can find funny, several-year-old comments in the code saying “This is temporary” or “Please don’t hate me; I’ll fix it later.” No one ever has time for real refactoring; that’s why beautiful, clean code is such a rare thing to see these days.
Juliet Dreamhunter, Founder, Juliety
Overreaching Design Skills
As a designer, I’ve often noticed that one of the most common fibs I hear from programmers is that they can handle the design part themselves. It’s understandable, though. In the tech world, there’s a lot of overlap in skills, and programmers are incredibly talented in their domain.
However, design is a whole different ball game. It’s not just about making things look good; it’s about creating an experience that’s intuitive and resonates with the user. While I appreciate the enthusiasm and crossover skills of my programmer colleagues, I believe design is best left to those who specialize in it.
Juan Carlos Munoz, Co-Founder, CC Creative Design
Related Questions
- What Are the Characteristics of a Bad Software Engineer?
- What Are Must-have Gadgets for a Programmer?
