Jun 01, 2021 Article blog
A program with 2500 lines of code must be better than a program with 500 lines of code? D evelopers who write concise, efficient, and highly available programs are leaving the market, and people who make big, complex and difficult-to-use programs can get a raise? H ow should the developer's work be evaluated? Take a look at the stories of the following two programmers.
Once upon a time, two companies, The Automated Accounting Applications Association and The Corporateized Computerized Capital Corporatio, decided that they needed a program to execute a business for their company, but they didn't know that the programs to be developed were exactly the same for their business needs.
Automated hired Alan, a programmer analyst, to solve their problems.
At the same time, Unifieded decided to put a new junior programmer, Charles, in charge of the job to see if he was really that good.
Alan had experience with difficult programming projects, so he decided to use the PQR structured design approach. W ith that in mind, he asked the department manager to assign three more programmers to the programming team. The team then began to work, pouncing on extensive preliminary reports and problem analysis.
Looking at Consolid's side, Charles wasn't busy doing it, and he spent some time thinking about it. C harles's colleagues noticed that he often sat at the table, put his feet up on the table, and drank coffee. Occasionally, he is seen busy in front of a computer, but colleagues can tell from the rhythm of his tapping the keyboard that he is actually playing the game of Space Invaders.
By this time, Automated's team was already writing code. Programmers spend about half of their project time writing and compiling code, and the rest of their time meeting to discuss interfaces between modules.
Charles's colleagues noticed that he was finally no longer addicted to Space Invaders. H e's either scaffolding his desk for coffee or scribbling on small pieces of paper. The handwriting he wrote on the small piece of paper was sloppy and certainly didn't seem to be playing Tic Tac Toe, a game, but it didn't make any sense.
(Recommended tutorial: JavaScript tutorial)
Two months later, Automated's team finally released a schedule for the implementation of the project. I n two months, they will release a beta version of the program. After two months of testing and optimization, you get a complete final version of the program.
At the other end, Charles's manager, who had been watching Charles fish at work, was fed up and had lost patience with Charles and decided to showdown with him. B ut when he walked into Charles's office, he was surprised to see him busy typing code in front of his computer. H e decided to wait and see what would happen, so he hit haha and left. H e began to keep a close eye on Charles in order to seize the opportunity to teach him a good lesson in person. But the expected unpleasant conversation didn't come up, as he was pleased to note that Charles seemed to be busy most of the time, and that Charles was even seen too busy to eat late for lunch, and that he would stay to work overtime after work two or three days a week.
At the end of three months, Charles announced that he had finished the project. H e submitted a program with 500 lines of code. T he program seems to be well written and tested to meet all the requirements of the project. I n fact, it even has some additional conveniences that can significantly improve program availability. After the program was put into practical testing, it performed well, in addition to finding an oversight that could be quickly corrected.
By this time, Automated's team had completed two of the four main modules required for the project. These modules are currently being tested, while others are complete.
Three weeks later, Alan announced that the junior version was completed a week ahead of schedule. H e provided a list of defects to be corrected. T he program begins to be used for actual testing. I n addition to the issues listed in the defect list, the user found a number of other errors and defects. A s Allen explains, this is not surprising. After all, this is a starting point, and mistakes are to be expected.
After about two months, the official version of the program was developed. I t consists of about 2,500 lines of code. W hen tested, it seems to meet most project requirements. B ut it cuts one or two features and is very picky about the format of the input data. H owever, the company decided to get on with the program. T hey can train data entry personnel at any time to enter data in exactly the required format. The program has since been handed over to some of the programmers responsible for maintenance to fill in the missing functionality.
(Recommended tutorial: Java tutorial)
At first, Charles's boss was more satisfied with his performance on the project. B ut when he read through the program's source code, he found that the project was really much simpler than he initially thought. Now, even for a beginner, it's obviously not that hard.
Charles does produce about five lines of code a day, perhaps slightly above the industry average. However, based on the simplicity of the procedure, his performance is nothing special, and his boss remembers his two months of "fishing."
On the next pay adjustment, Charles was given a raise, about half the inflation rate of the period (poorly) and the company did not give him a promotion. About a year later, he became disillusioned and left Consolid.
At Automate, Alan was rewarded for completing the project on schedule. H is superiors looked at the programs they had written, and he browsed for a few minutes, well, to comply with the company's standards for structured programming. T hen he soon stopped trying to look down, and the program seemed hard to understand. Then he realized that the project was indeed much more complex than he had originally thought, and he once again congratulated Alan on his achievements.
Each programmer on Alan's team produces more than three lines of code per day. T hat's about average in the industry, but given the complexity of the problem the project is about to solve, it's a pretty good output. Alan received a generous pay rise and was promoted to systems analyst in recognition of his achievements.
(Recommended tutorial: python tutorial)
Comments from Tim Mensch:
I used to be a young but intelligent programmer, and this story resonated strongly with me. E ven when I was a new person in the workplace, I was able to do things that were challenging for many senior developers. I n my first job (as a game developer), my manager said that the code I created in a few days felt better (physically) than the code that a more experienced developer had done after months of scrutiny. I n my second job, I optimized a tool program written by a senior developer with more than 10 years of experience to complete a task in a fraction of a second, rather than a few minutes. My whole career has been filled with such a series of anecdotes.
In my many years of development and learning experience since I worked in programming, I realized that experience is really important. H owever, the underlying skills are equally important. In fact, like the fables of the two programmers mentioned above, the underlying skills may be more important than experience, a fact that I think has been overlooked by many contemporary developers.
Having said that, I've stepped on a pit to keep up with the second developer mentioned in the article, creating a much more complex system than is actually needed. I know a complex solution and know I can implement it, but that doesn't mean it's the best solution, and I need to remind myself of that from time to time.
So I tried to compromise and even questioned my own solutions, constantly looking for ways to improve and simplify them. I 've been accused of because I tend to spend more time thinking about a problem than just solving it in obvious ways; Because I spend a lot of time thinking, it may seem like i'm not doing my job properly, but thinking fully allows me to produce better results---- less code, stronger, more scalable, and easier to read.
That's why I think the fable above is so important. D evelopment experience is important, but skills in project design and implementation can be successful, and if you have both experience and skills, you can achieve considerable miracles. As long as you keep questioning your idea and thinking about how to perfect it better, don't just think your first design idea is perfect enough.
Original link: realmensch.org/2017/08/25/the-parable-of-the-two-programmers/?