Meetings, managers who don't know anything, productivity metrics - that's the chasm between you and the next great software.
The product had to be released yesterday. Users scrambling and ranting about a missing feature. The boss's boss said we better act fast or we'll be fired. Feeling all powerless.
No one is satisfied with the speed at which developers are already "doing their best" to change the world, everyone wants the code to flow like water from a fire hose, but no one is willing to give developers something to do their job better condition. Like the boss who wants us to get the job done yesterday, he doesn't want to hire more people, buy a faster machine, or do anything else that would allow programmers to focus on programming, and he wants horses Run without giving the horses grazing.
Here are 15 real-world programming obstacles.
Programming Productivity Barrier No. 1: Meetings
The most common complaint is meetings that interrupt developers' coding thoughts. If the boss trusted the programmer, he would ask them to go to that dimly lit conference room every now and then to chat about details. While programmers usually blame managers for ruining meetings, they occasionally blame other programmers for coming over and asking questions about bugs or features or architectural strategies.
While some of the complaints are stupid -- but programmers still complain if their bosses let them grope in the dark, with no communication at all -- and let them drown in the abstract world of software and face all kinds of hardships on their own . Fast food chefs and coffee blenders may also be able to juggle different needs, but switching the brain to the right mode to operate abstract algorithms often takes time. Switching from meeting mode back to encoding mode can waste an hour or so of work time.
Programming Productivity Obstacle No. 2: Answering All Emails
If meetings suck, this one is probably worse: the need to check the endless amount of emails that come in. Replying to emails takes time, and no one is satisfied with the response. Then the most impatient developers might opt for the simple reply - "tl;dr" (ie too long, didn't read. Too long, didn't read).
Some teams are trying to create a one-day-a-week no-mail day. Other teams don’t use email at all. While it solves the problem of email overload, it comes at the cost of communication. If suddenly not working together. Is this even a good idea?
Programming Productivity Barrier No. 3: Trying to Measure Productivity
There will always be management teams inspired by books that say "you can't manage what you can't measure" and start measuring commits or codebases or lines of software code or bug fixes. To count is to measure, they believe, and to measure must be a good thing.
But programmers are not bricklayers, and they can't count how many bricks they have laid to know their efficiency. Instead, in order to write better code, programmers need to either focus on the lines of code written, or fix bugs, or commit to code repositories, or do innumerable things. If bug fixes are a plus, reports of minor bugs will proliferate, as will bug fixes. Someone gets rewarded for reporting a bug, and then another gets rewarded for fixing it. Or, if it's counting lines of code, programmers who can solve a problem with 10 lines of code might turn to saying that 5,000 lines of code will be more flexible or functionally compatible -- anything that can be added to 5,000 lines of code. add in.
Measuring efficiency can actually make codebases worse by encouraging feature-rich, over-engineered long files.
There is no real workaround for this problem. We need to track down bugs. We need to organize the workflow and coordinate the creation of the software. This elegance is immeasurable.
Coding Productivity Barrier No. 4: The Arrogant Developer
For programmers, there is a colleague who is more intolerable than Boss: creating the last iteration of the code, but no longer working on the project. Just as every home improvement contractor will belittle the skills of the last carpenter, so will every programmer be quick to point out the horrific, inexcusable, and utterly dead-headed behavior of the previous generation.
Sure, that may be true, but it's rarely as bad as programmers say it is. If anything, the problem isn't usually due to lack of skills either. The main difference is the style, and the style will change over time. The previous generation was different from the library we access today. They also haven't read the latest books on best practices.
A arrogant programming attitude tends to slow down projects. A mix of pride and egoism can lead programmers to throw away fully competent code in order to rebuild it the "right way" they think it is.
Programming Productivity Barrier No. 5: The "Fix Later" Mindset, aka "Technical Debt"
We always feel like we don't have enough time to build what we want to build on schedule in our projects. So we cut corners, patched the code, and covered it with virtual tape. Wise managers once called this "technical debt," because "debt" is something that must be paid later. Even if they don't understand the code, they know what "debt" means.
Every project has a certain amount of technical debt. Sometimes it works quickly, but usually it's not until the next generation finds out that this has become a pit. They need to build what the previous generation didn't do. Like a snowball, it gets bigger and bigger.
Programming Productivity Barrier No. 6: Non-Programmer Managers
There will always be guys with smiling faces and neat suits who don't major in computer science and don't understand programming projects who become managers. Maybe they married the boss's daughter; maybe they were in the "right" place at the "right" time. But the boss made them managers even though they didn't know anything. To make matters worse, they will look at the problem with the eyes of a layman, even if it is nondescript and the text is not appropriate.
There are some programmers who say such managers are welcome because it's easy to fool them. And they also took on fire from higher management. But others admit that these people just keep meeting and only get in the way of programming. They can hardly give any useful guidance, all they can offer is a little quality check.
Programming Productivity Barrier No.7: Programmer Manager
While programmers may complain about having to deal with non-programmer managers, they often quietly say that it's worse -- and sometimes much worse -- for programmers to be managers.
They're the geniuses of their predecessors who might decide to micromanage a project and then decisively tear apart a swathe of code because they have a new outlook. Or maybe they'll gossip about how they wrote half the code in 8080 assembly or C or Java programming for the same thing. In any case, they are more obsessed with the technical details than the big picture, although they are hired to keep an eye on the latter.
Programming Productivity Barrier No. 8: The Social Programmer, aka "brogrammer"
While programmers can blame the eloquent sales team for every problem and any outage, programmers must also admit that some of the problems are their own. Programmers are hired for their computer skills, not their people skills.
Programmers are often bad at communicating and don't know how to express their feelings and thoughts. They can accurately grasp the technical parameters, just as easy to handle. It doesn't matter what the client wants to change: programmers are always thinking about technical parameters, even at a company picnic.
While programmers can often filter out each other's idiosyncrasies, it can also fail teams when programmers stumble. When two people on the same team have different political views, say, dynamic languages or NoSQL, the team will never have peace. Everything seems to be on the battlefield, with the flames of war and the smoke of gunpowder filling the air.
Programming Productivity Barrier No. 9: Selfish or Cowboy Programmers
Did you find a null pointer in his code? Catching null pointers then becomes your job. You'd better think twice about passing a zero, because selfish programmers don't check for divide-by-zero errors. It also becomes your job.
Cowboy programmer's job is cool and fast, but that's because his code has many bugs left and it's not tested. So it becomes your job too, because if you don't handle the chores, the code will crash.
Many teams finally realize this too late. The code block worked fine in early tests, but when real data was entered, various problems started to surface. What a disaster.
Programming Productivity Barrier No. 10: Poor Documentation
Writing documentation takes time. But since our boss hired us to write code, and we are usually measured by the number of lines of code we write. So since you want results, let's just do the part you want. Of course we will still write documentation in the end, but it doesn't matter if the quality is good or bad.
Sometimes the documentation, while extensive, is a version of old code that is months or years old. We just haven't had time to revise these old docs, but we'll sync later - trust me.
Programming Productivity Barrier No. 11: Becoming a Document Slave
While we've all experienced projects without documentation, it's not uncommon for projects to fail due to too much talk and too little coding. A few people once pointed to a shelf full of folders and boasted to me, "I've hired someone to do the documentation." But it would take a year to read through that many documents.
Programmers usually write comments and comments when working on requirements, which are then used as documentation. Therefore, such documents are all small details, not carefully summarized or not to the point. This can be fatal in the documentation, when they just write code journals without providing much abstraction and understanding. Such documentation is not inspiring, just translating the code.
Programming Productivity Barrier No. 12: An environment that can easily lead to distractions
One client insisted that I go to their office every day and insisted that I use their computer. Then, they didn't provide any office space, so I had to write code in a conference room with six interns, who also needed half a day for me to answer questions they had the night before. The other half of the day is used to dictate what to do tonight. So, I basically can't do my job.
While sales and marketing teams can thrive in environments with background noise, programmers often need library-quiet backgrounds. Small talk, distracting taps, or bells will drive the programmer's mind out of the abstract workspace and back into reality. Then, it takes a few minutes to re-immerse in the workspace.
One developer told me he hated his new desk because it was so close to the air conditioner vent that it was incredibly loud and made it really hard for him to concentrate. This may be a slight exaggeration, but it is a fact.
While many businesses provide programmers with ping-pong table-like entertainment, they often forget that developers need to concentrate in a quiet atmosphere. They even moved programmers to a large room, thinking that it would promote cooperation, but it would cause programmers in the entire room to be disturbed if there was a disturbance.
Programming Productivity Barrier No. 13: "Cultural Fit"
Do you want to have your own office? Or do you prefer a team office so you can call out your questions directly? Do you like to start work early in the morning, or do you prefer to stay up late?
If styles are similar between team members. Then the team tends to work better. Teams that fail to find common ground quickly fail. If there is no communication, in the end, it will only go in the opposite direction.
Programming Efficiency Barrier No.14: Sticking to Traditional Technology
Many defenders believe the ancient technology is still great and still gets the job done. So there are doubts about why the code should be rewritten.
They were right, but they forgot the cost of keeping this ancient code. Everything usually needs to be translated with custom code. Some codes are even written before ASCII, which means input and output need to be converted. Older systems often count space characters just to indicate in the database what it is. This requires more conversion.
Of course programmers can do a lot of work by screen scraping, reformatting, and ad hoc building the system, but after a while, they often have to spend more work cleaning up the chaotic logic than they have time to write new ones logic.
Programming Productivity Barrier No. 15: The desire for the latest
The newest tools are naturally interesting, but they won't be adopted by development studios without spending a lot of time recoding the old work. People who are on the cutting edge will always throw away entire parts of the API and rewrite it, forcing us downstream programmers to rewrite the code along with it. I'm tired of having to try my best to use Python 2.7 code against Python 3.0 code because Python is a relatively stable codebase as it stands.
In many cases, the new tools were not combat-oriented. For example, Node.js, while quite fast, only works if you know that threading takes precedence after you relearn all the lessons about deadlocks. There is no free lunch in the world, tools are good but they all come at a price.
Translation link: http://www.codeceo.com/article/15-barriers-to-better-code.html
English original: 15 workplace barriers to better
code