Product Growth at Codegiant
You might think a profession based on logic and learning would be immune to folklore, but the developer community remains rife with myth — myths so pervasive they begin to manifest into reality.
If all the programming myths were true, the programming world would look like a cohort of 20-something geeks (some 10x better than others) using their elevated math skills to code at all hours of the night. Well, as you probably know if you’re in the field, that’s simply not the case, nor are some of the things developers themselves believe about the industry. Let’s debug those myths:
Here’s where we insert a picture of Silicon Valley: a room of hoodie-clad guys hooked up to Red Bull IVs. There’s some truth to this, especially with startups. However, it doesn’t always have to be this way, and research would suggest that long hours and sleep deprivation don’t actually increase productivity. In reality, there’s a blurred line between effort and progress, and usually an outcome of unrealistic expectations. Plenty of developers have families and lives outside of programming, and would rather leave the office at a normal time. Instead of allowing that idea to persist, the programming community would benefit from looking at ways to improve workflow, and set realistic goals with agile methodology.
Offshoring usually does the opposite, companies are only attracted to the idea because it seems cheaper. However, hiring more programmers for less money definitely doesn’t mean faster. It involves more communication overhead, training, and effort in repartitioning. Offshore development teams are also prone to higher turnover rates, meaning that the long-run desired effect becomes void. In this case, the in-house team has to pick up the slack and savings diminish.
As mentioned above, offshoring doesn’t necessarily lead to cheaper software done faster. People will continue to try this model until it has proven worthless, but offshoring is not going to suck all the jobs from the U.S. The facts remain: language does matter. Attempting to communicate with offshore managers and teams is unreliable, and tumultuous. Clients normally run out of money or patience dealing with offshore teams and turn back to the dev shops in the country where contracts can be better enforced.
Eric S. Raymond coined the term, “given enough eyeballs, all bugs are shallow”. It is a commonly held belief that in open source software that bugs will be found, reviewed, and fixed, because anyone can take action. Truly, more people are using open source software than contributing, and most are not capable of correcting mistakes in code. In other words, too many cooks spoil the broth. A better way to is to use a concentrated team equipped with great bug tracking software.
Yes and no. Math skills don’t necessarily translate into being a good developer. If someone isn’t mathematically inclined, they may be better at certain aspects of programming that require one to be clever or practical. Outside of gaming, most developers are only using basic algebra and statistics to find out how efficient the code is, and even that is minimal.
You don’t need to be a genius to be a programmer, you just need the drive and ability to learn. Programmers are constantly faced with mistakes that can be frustrating, and the best developers are those that can fail repeatedly and learn from mistakes.
Learning never stops because the world of programming moves at light speed. It’s smart to master a language, because you’ll have an ability to work well and understand the nuances. However, never get stuck only knowing how to do one thing, you’ll end up knowing about ‘legacy’ software no one uses.
You may be able to learn the basic tenets of a language in two or three weeks, but you surely cannot be a master. Mastering a language requires interest, patience, and most importantly — application. You wouldn’t want a doctor operating on you if they had only read all the medical textbooks and taken the tests, you want someone who has spent countless hours actually participating in surgeries. Think of yourself as a surgeon, because the same muscle memory is needed to be a good developer.
In 1968, Edgar Dijkstra talked about the ‘software crisis’, which referred to building software that was inefficient, over budget, low quality, and difficult to maintain. Today, the fact that ‘buggy’ software costs the U.S. billions of dollars purports the ‘crisis’ although there’s no real crisis to speak of. Software isn’t doing too bad, it’s always improving. It commands a large chunk of the economy while moving at lightning speed, and there will always be hiccups in efficiency as new software emerges. No need to panic, the crisis is a myth.
Software is rarely finished. Sure, management and developers would love to believe that large, multi-layered a software is in constant flux, the developers who made the software aren’t perfect, applications change, added features introduce new bugs. Management and teams need to consider support and maintenance costs, and account for continual innovation that a product must upkeep to stay competitive.
Management often thinks that developers are just translating an ideation into code, without understanding the decisions that developers make along the way. It’s quite a misunderstanding, because developers are building and making decisions for the project every step of the way. There are plenty of non-functional requirements and design decisions that developers make every day, and good developers are ones that can track those, communicate important decisions with a team, and make executive decisions on minor details.
Yes it’s technical & logical, but it’s also an art form. Many non-programmers overlook the beauty in construction of code, and some developers may even believe this too. Many programmers would say it’s like poetry. It’s absolutely a creative effort. Paul Graham outlines the artistry of coding in his essay Hackers and Painters.
A lot of people have the idea that programmers are loners who like to sit alone with their computers and code all the time, and when faced with social situations aren’t savvy contributors to an organization. Frequently, this leads managers to interact with developers in a way that underestimates the contribution of a development team. When managers do this, they are putting themselves at risk for a resentful team. Developers make decisions constantly in their code, and come in all shapes and sizes, just because you enjoy coding doesn’t mean you prefer solitude.
Developers often operate under the belief that managers have no skills and are useless in guiding the development team. This isn’t true, most managers really know what they are doing, and exist to shield their team from distraction, provide them with the best tools, and manage deadlines, budgets, and bring in extra resources when needed. People tend to focus on the negatives, so managers get blamed when things get frustrating, but their purpose is to make things run more smoothly for their team.
Maybe it’s just a symptom of age, but developers early in their career tend to think they are better than experienced developers. They learned a new technology they believe to be more productive, and are in turn more valuable than someone using old platforms. Many developers continue to learn new technology as they get older, as they should. The fresh out of college developers are overlooking an important factor: the depth and breadth of experience that only comes with time.
Everyone is bored by something, but you don’t dedicate your life to something that bores you. Coding can be fascinating, it’s a mix of architecture, math, and language. People who think coding is boring don’t understand the intricacies, but developers know that coding is all about coming up with solutions and learning — how could that be boring?
Ageism in the programming world is real, but age is not what ends a career. Individuals who get stuck in one language, or fail to learn new platforms and technologies contribute to their own waning relevance. This is not to say that developers leave programming entirely, many move into management positions or start their own companies. Others continue learning and loving developing for their entire career, it’s just a matter of staying up-to-date.
Often people think a person who writes more lines of codes is more productive, but developing isn’t brick laying. Hiring cheaper programmers and expecting the job done exactly the same is irrational. Developers are people! They have specific skills, personalities, and knowledge. Like a language, some programmers will be better at one project than another, and that’s what will influence efficiency.
By the way, if you are looking for GitLab / Github alternative, feel free to check Codegiant. We boast with simple and intuitive UI / UX and all the features GitLab offers :)
Previously published at https://blog.codegiant.io/20-programming-myths-5c6155964231