coder . cl

Recently on a proggit link, rated with 593 points, refers to programming as an intense mental activity. That’s true, you must think too much while you are programming, you need to memorize parts of your code, retain the whole view of the algorithm in mind and related stuff. Programming is not an easy job, among other things it requires good communication skills and good technical project leaders, so they can handle which their programmers talks when they are in front of a problem, and of course, is not that easy that many as people thinks.

think more, code less

A programmer spends about 10-20% of his time writing code, and most programmers write about 10-12 lines of code per day that goes into the final product, regardless of their skill level. Good programmers spend much of the other 90% thinking, researching, and experimenting to find the best design. Bad programmers spend much of that 90% debugging code by randomly making changes and seeing if they work.

You need to think on your code, not just to dump what you think that will work on your editor. Who has worked with me knows that some times I wake up from me chair to walk a little, to smoke a cigarette or to take a coffee. Not all that activity was all the time handled as distraction, many times was made with the intention to find a good solution. Other times, I’ve spent some time searching for solutions on Google — why to reinvent the wheel?.

Now I have half projects related to web development and other half projects related to system programming. Web development is relatively well documented, you can find blogs, examples, pre-built third party solutions and related stuff which will fit pretty well in your project. System programming requires more effort, and more concentration. For example changing blocking algorithms for non-blocking algorithms on asynchronous servers is a hard task, searching for memory leaks on Python Extensions such as pyxser, where valgrind can’t handle all memory leaks since Python uses its own memory allocator and garbage collector is hard too. And most tasks that require mental intensive work can not be made using quick and dirty solutions. For example is common for some bad programmers to hide compiler warnings in PHP using error_reporting(0) and also is common for bad programmers to ask how they can hide compiler warnings. IMO, a good programmer face all compiler warnings and errors and uses pedantic compiler flags. For me that’s a sign of good practices, not those quick and dirty solutions. Some good Python programmers are using some nice Python flags, like -Qwarnall, which leave you good warnings about possible mistakes on your code while your are testing it. Along the time, the usage good usage of compiler or interpreter warnings will lead you to avoid some mistakes while you are coding.

productivity

A good programmer is ten times more productive than an average programmer. A great programmer is 20-100 times more productive than the average. This is not an exaggeration — studies since the 1960′s have consistently shown this. A bad programmer is not just unproductive — he will not only not get any work done, but create a lot of work and headaches for others to fix.

Well, here I will omit my opinion about my experience. It’s easy to see horrifying mistakes on code, such as the old, but well known, "Null References: The Billion Dollar Mistake". If you know all those problems that can cause a NULL reference, why are you skipping those checks?. You can find great tools to check your code, from static checkers to runtime checkers, plus the proper compiler/interpreter flags will lead you generate code with less errors. Along the time you will be more productive, creating more precise code and elegant one. For example you can read the Zen of Python about how a program must looks like. Following programming rules will also lead you to more productive approaches on programming, being rigorous with your programming practices will keep your more code clean of bugs.

Then, how do you think about the problems that your are facing on programming will get a precise perspective on how the solution must be implemented. Think more, code less. If you a have technical leader or project manager that interrupts you every time with different problems, producing a high rate of context switching between projects, you must leave that job. It will cause many problems in your code, then will cause many problems for the rest of the programmers on the team, and finally the company. Also is possible that it will cause stress and related sickness in your mind, due to the intense effort that requires a switch between one project and other, it will bring you weariness and you will be less productive.

As team leader or project manager, you must organise programming sessions, each session to deal with one specific project or problem, and not leave that session until the problem is solved. If you do a context switching between two sessions leaving a problem unsolved, you will get weariness in your programmers and also the guaranty of buggy code. This do not means that the session can be interrupted by a cup of coffee or a cigarette, it can help you to think a little on the problem out of the computer with more comfort. Solutions will be more elegant and the problem will be really solved more quickly than you think.

reaching good design

Great programmers spend little of their time writing code — at least code that ends up in the final product. Programmers who spend much of their time writing code are too lazy, too ignorant, or too arrogant to find existing solutions to old problems. Great programmers are masters at recognising and reusing common patterns. Good programmers are not afraid to refactor (rewrite) their code constantly to reach the ideal design. Bad programmers write code which lacks conceptual integrity, non-redundancy, hierarchy, and patterns, and so is very difficult to refactor. It’s easier to throw away bad code and start over than to change it.

Do not expect a good design using a whip over your programmers, of course they will fall in the quick and dirty solution that will lead your project to the total failure. A good design requires thinking, and you can not type code and think at the same time, so you are a bad project manager that knows nothing about programming if you hurry your programmers, and if the project fails, that will be your failure, not of your programmers. I can bet that every project manager or team leader that hurries their programmers are the project managers that have more problems in their projects, despite the good qualification and recognised quality of their programmers. Remember, programming requires thinking and it’s an intensive mental activity, is not about playing World of Warcraft or Doom killing those bugs in your project.

If you have well organised programming sessions for each problem that you face, you will get more clean code, robust one and it will fit a very good design as final product. Each programming session can be organised in a simple ToDo list, where each ToDo item can represent a sub-problem of the programming session task. For example if you use user stories as your task organisation atomic component, you as project manager or programmer itself, can identify sub tasks. If you have "the user enters enters his address information", you can divide that story in sub-problems, attacking each part of the problem for example: "the user enters the zip code, and it’s validated against his state". Finally, you can comment all those tasks in your VCS commit with the proper comment. Personally, I use KArm and KOrganizer to track my ToDo lists and ManyMoon to track my projects. The key is the proper organisation on how we face the problems. But again, we must think on which sub-problems of each assigned task that we must face.

If you are being whipped on your job, of course you must leave that job, since that project manager do not have experience in programming or that project manager of course was a bad programmer. Note that whipped and hurried are conceptually equal, you can bring similar suffering hurrying your programmer just due to the effort that requires a context switching.

bad communication, software rot

Software obeys the laws of entropy, like everything else. Continuous change leads to software rot, which erodes the conceptual integrity of the original design. Software rot is unavoidable, but programmers who fail to take conceptual integrity into consideration create software that rots so so fast that it becomes worthless before it is even completed. Entropic failure of conceptual integrity is probably the most common reason for software project failure. (The second most common reason is delivering something other than what the customer wanted.) Software rot slows down progress exponentially, so many projects face exploding timelines and budgets before they are killed.

Probably, here the failure is the how are you communicating the project concepts. A written specification should be enough, but if don’t have the proper meeting to explain global ideas and make the proper induction to the project, it will fail. The same happens if you don’t have the proper meeting to clarify the project goals and questions that your programmer can have. Both meetings are essentially strong enough to leave concepts related to the project completely clear. On that case, agile methodologies and simple tasks like scrum sessions are rocking. You constantly are communicating goals, problems and advances in each project. Currently I’m working as freelancer, and usually I have scrum session meetings, so every customer knows how it’s going his project and also he knows which artefact or question needs to be solved to allow the project to be continued.

As result of constant communication, through meetings — most of them through skype — without the need of presentational meeting, I have very good results. Usually we have a common language, for example a customer who recommends me says: "…His flexibility to move from C++ to PHP, Java or JavaScript and back within the same project and conversation has impressed me considerably…". Obviously, he understands every idea that I communicate, and every problem that we face, as customer and provider. Being clear on communications is a must, among other things on transmitting concepts between developers and project managers.

Is important to have project managers that have real experience on programming, and have pretty clear concepts about what it means. The same applies to the technology which is used, the project manager must know very well the scope of the technology used. In other case, the project manager will indirectly generate enough entropy in the code to rot the software.

programming is a 24/7 work

Programming is hard work. It’s an intense mental activity. Good programmers think about their work 24/7. They write their most important code in the shower and in their dreams. Because the most important work is done away from a keyboard, software projects cannot be accelerated by spending more time in the office or adding more people to a project.

I have no words to describe this. That becomes real, and certainly you will want to hire awesome programmers, but also you must know that some programmers will not agree with you if you are willing to use their passion to take advantage from them, and you don’t get the fact on how to read a resume for a programmer position. Most programming jobs requires passionate people for their work. But you must not take advantage from them, you must know that due to the intense mental activity that they are constantly executing, probably they are smarter rather than the wrong idea that you have about them.

If they are passionate programmers, they will think on the problems that they are facing more than other programmers. Usually a bad programmer just forgets what he was doing on the job, do not reads any books about programming and is not interested on enhancing his ability as programmer. Usually a bad project manager do not listens to the words that comes from a programmer, his mediocrity about his absence of the capacity to listen people generally will lead the project to the complete failure. Is not capable to appreciate the work of their programmers and usually will bring you more than one headache due to his wrong decisions on the project.

Certainly, if you are a passionate programmer, if you don’t get enough appreciation of your work, if you have FOSS projects, reflecting your passion for creating good solutions, you must leave your job. People who don’t understand that, do not have experience on what programming means, for those people, programming is just another job, and will take a look on your resume seeking for your certifications and qualifications, instead of what have you done in your career. Another customer who recommends me says: "His breadth and depth in coding practices and delivering high quality results in an efficient manner is unrivalled. I would recommend Daniel in any software development capacity, no matter how complex.". That capacity to deliver software on that way, comes from my passion, but you will not take advantage from it, it has a cost, since I’ve invested on good books — I’ve read about 80 books on programming and computer science, and I’ve paid for 60 of them, plus other 200 papers about programming and computer science too — so, you can’t hire me for a lesser cost of that investment, and I’m continuously reading and enhancing my knowledge about programming…

conclusions

Due to the hard that is the programming job, it is not a simple task. Is not mechanical, it requires creativity and also it requires good practices. Programming is very dynamic, you face different problems, and indeed sometimes it has common solutions, but requires to think about how to implement that common solution. I will not agree that someone will be my boss if he/she do not have real experience on programming, have at least one personal project, FOSS or not with a considerable feature that solves a particular problem. For example at my side I have pyxser, which solved cross and circular references in XML serialization, which I think that has not been solved before. Call me elitist if you want, but I have no options. In other way, you will be my customer and you must believe what I say to you, since I’m the one with experience in software development.