davisayer

Thomas J. Bing and Edward F. Redish of University of Maryland analyzed how physics students work on assignments using computer programs:

Symbolic calculators like Mathematica are becoming more commonplace among upper level physics students. The presence of such a powerful calculator can couple strongly to the type of mathematical reasoning students employ… Mathematica plays an active role in focusing and sustaining their thought around calculation. These students still engage in powerful mathematical reasoning while they calculate but struggle because of the narrowed breadth of their thinking. Their reasoning is drawn into local attractors where they look to calculation schemes to resolve questions instead of, for example, mapping the mathematics to the physical system at hand.

These computer tools affect thinking and how students frame and focus their work.

Can we find similarity with the way tools affect programmer’s mindset ? In essence, software programming is operation on ideas and knowledge. We translate people ideas into the source code. But we cannot do it effectively without programming platform and tools – editors, compilers, debuggers and may others. And they have profound effect how we approach and solve customer needs. Our platforms and tools could frame and alter our thinking. PHP, Visual Basic, Java, .NET, Ruby On Rails programmers with the same level of experience will build not only technologically different solutions, but in the most cases solve problems different ways.

Programmer’s platforms and tools affect our mindset in three ways:

• Tools could prevent normal flow of idea implementation. Inconvenient tools, cumbersome environments and long feedback cycles stagnate productivity and lead us to the path of the least resistance, often far from optimal.
• Tools could make ineffective implementation strategies more attractive, affecting how we frame customer ideas. For example, UI-oriented programming environments could shift programmer’s mind to think about the problem in terms of screen elements and UI events (Smart UI) instead of reflecting in the code domain concepts, relations and ideas (Domain Driven Design).
• Tools could shift focus to the implementation perspective from the big picture and broader context of the problem at hand. Narrow focus on implementation and technology has negative impact. Often redefinition of the problem, analysis of alternatives or refining of concepts could bring much better results. Inexperienced programmers (and even experienced) often get into this trap, concentrating on tools the same way as novice drivers are more concentrated on the handling a car instead of observing the road and finding the better way.

What qualities should effective programmer tools have?

• Usability – enhance flow of programmer’s ideas or at least don’t impede and interrupt this flow. Tools should be convenient, easy-to-use and aligned with the way programmers work. Programmers should put most of their mental energy to think about customer ideas and much less how to deal with these tools.
• Representation – enable easy for understanding and modification representation of the structure, ideas and domain concepts in the code. Tools should provide a convenient solution view, organization and navigation for understanding, parsing and manipulation with components, classes, relations and concepts. Modern source-based project organization could benefit from tools like Resharper. Martin Fowler blogged about more radical approaches as repository-based code and Language Workbenches. UML, MDA and code auto-generation tools didn’t prove to be useful for effective code representation.
• Agile development friendly – support evolutionary design, short delivery cycles, refactoring, unit testing and other agile practices.

What do you think? What are the best tools for the programmer to enhance concentration on the problem, unobtrusive flow of thoughts and effective implementation of ideas?

Link: Symbolic Manipulators Affect Mathematical Mindsets, Thomas J. Bing, Edward F. Redish

nuanc

Cross Talk complains that the selection of Java as the first programming language in Computer Science education weakens programmers skills and lead to decline in qualification.

The irresistible beauty of programming consists in the reduction of complex formal processes to a very small set of primitive operations. Java, instead of exposing this beauty, encourages the programmer to approach problem-solving like a plumber in a hardware store: by rummaging through a multitude of drawers (i.e. packages) we will end up finding some gadget (i.e. class) that does roughly what we want. How it does it is not interesting! The result is a student who knows how to put a simple program together, but does not know how to program. A further pitfall of the early use of Java libraries and frameworks is that it is impossible for the student to develop a sense of the run-time cost of what is written because it is extremely hard to know what any method call will eventually execute.

Authors noticed other worrisome trends in teaching software professionals:

1. Mathematics requirements in CS programs are shrinking.
2. The development of programming skills in several languages is giving way to cookbook approaches using large libraries and special-purpose packages.
3. The resulting set of skills is insufficient for today’s software industry (in particular for safety and security purposes) and, unfortunately, matches well what the outsourcing industry can offer. We are training easily replaceable professionals.

I want to look into this problem from the broader perspective: what is the best way to become a good programmer for a beginner? There are two fundamental ways:

1. Strong theoretical foundation: learn applied math, theories of algorithms and computational complexity, read Knuth’s The Art of Computer Programming, solve problems with Turing machine, etc.
2. Shu Ha Ri – learning by experience: learn programming by solving practical problems with modern languages and platforms (Java, .Net, Ruby On Rails, PHP). Fundamental knowledge emerges from experience in solving real problems.

Definitely, there are some domains that require and intensively use CS theoretical knowledge: science, engineering, hardware and system programming. However, majority of software professionals build software for solving business, personal and other non-rocket science problems. I know a PHP programmer, who doesn’t know how to write a sort algorithm (without looking somewhere), but still have built several successful web applications. And I’m confident that there are strong computer science theorists who cannot write easy-to-use programs and make their customers happy.

So, what is the best approach? I believe any beginner should excel in following three areas:

1. Train clear logical thinking. The ultimate end result of any programming is a program (I hope it is not a surprise), which is a set of instructions for a computer. You cannot write instructions if you don’t know how to achieve end result. Any language which allows clear procedural expression of logic is fine for start (e.g. Pascal). I would add object-oriented and functional languages on later stages (e.g. Ruby and Lisp).
2. Understand modern software concepts and environments: computer architecture, networking, web, mobile, concurrent programming, cloud computing, etc. High level knowledge will give better orientation, starting points and overall understanding of software systems mechanics.
3. Learn to effectively implement customer needs. Happy customers and useful software is the end result of any healthy software project. Learning evolutionary, agile development and user experience (including communication and psychology) practices is essential for the effective software developer.

I believe that software development is empirical in nature. Math and computer science theories are great, but in many case they will be only brain exercises without practical results, especially for beginners. On the contrary, beginners will become excellent master programmers by succeeding in discussed above three fundamental areas and relentlessly learning from experience in applying them.

What do you think?

Links:
Computer Science Education: Where Are the Software Engineers of Tomorrow?, Dr. Robert B.K. Dewar and Dr. Edmond Schonberg
Is Software Development Empirical or Rational?

Wired magazine published a very interesting article about change in US military philosophy during the Iraq war. US started with idea of Network-Centric Warfare:

The US military could use battlefield sensors to swiftly identify targets and bomb them. Tens of thousands of warfighters would act as a single, self-aware, coordinated organism. Better communications would let troops act swiftly and with accurate intelligence, skirting creaky hierarchies.

The Army committed more than $230 billion to a network-centric makeover, on top of the billions the military had already spent on surveillance, drone aircraft, spy satellites, and thousands of GPS transceivers.

Advanced technology helped to achieve quick victories – the opposing forces in Iraq (and Afghanistan) were broken in matter of days. But years of struggle to establish the new order came after these victories. Seizing territory and destroying enemy forces was not enough for the success. American military have learned from these failures and started to change approach recently. They realized importance of winning trust, minds and hearts of local people to win the war.

General David Petraeus, commander of Multi-National Force in Iraq, knows all about these mind games. He oversaw the writing of the new counterinsurgency manual. The book counsels officers to reinforce the local economy and politics and build knowledge of the native culture, “an operational code’ that is valid for an entire group of people.” And the manual blasts the old, network-centric American approach in Iraq. “If military forces remain in their compounds, they lose touch with the people, appear to be running scared, and cede the initiative to the insurgents,” it says.

Sometimes software development projects are closer to military operations than to the engineering process. The situation often changes, pressure is building up and quick decisions are required. The software system is the end result of these operations and developers are in the forefront. The software system campaign is not finished after the initial development is over: people start using the system, administrators support it and developers continue evolving it over time.

What skills can developers learn to contribute to the overall success of the long software campaign beside coming with technical solutions?

We often rely on technology, new tools and smart strategies to win our software battles. But at the end, people will decide the fate of the software. Should we teach programmers how to win minds of people who use their software in addition to mastering superiority in technology solutions?

Part 1. Gaining processing power
Part 2. Becoming intelligent
Part 3. Interacting with humans
Part 4. Building useful programs
Part 5. Future of human programmers

Computers don’t retire, overreact and complain. They could in minutes get all the knowledge accumulated by other computers. They could work 24 hours without making stupid mistakes. They make more and more human jobs obsolete. It is inevitable, computers will replace programmers in many areas. Even more, if Strong AI, capable of reasoning and understanding meaning, will appear, programming as a profession will be almost eliminated (at least coding part). Customers will be able to describe their needs directly to a computer. Computer AI will be translating these specifications to machine code (and stronger AI will require less formal specifications) and relentlessly building the software system.

Does it mean that that at the some point in the future software developers will no longer be needed? It could be true, if customers could specify exactly what they need and can effectively collaborate with AI to build the system. But things are not so simple, especially with non-trivial problems and humans (assuming that customers and users will be still humans). There are three roles that software specialists could play in the future even with powerful computer programming AI.

Read full post >>

Part 1. Gaining processing power
Part 2. Becoming intelligent
Part 3. Interacting with humans
Part 4. Building useful programs
Part 5. Future of human programmers

Is it easy to build useful programs for humans? Failure rates and dissatisfaction with the software projects (more than 50% still fails or challenged) show that it is not quite easy task. Can AI help to build more successful projects, compete and eventually replace human programmers?

From ideas to specifications

Human programmers face objective challenges in building software systems, which AI will face in the future:

1. It is difficult to understand what people need.
2. Customer’s ideas are shifting, once they start using the real system and experience all the consequences and effects for interacting with it in the context of their problems.
3. Customer’s needs are changing constantly reflecting outside business and company trends, situation and problems.

Read full post >>

Marc Andressen quotes Frans Johansson’s book “The Medici Effect”:

In a [1987 study, researchers] concluded that brainstorming groups have never outperformed virtual groups. Of the 25 reported experiments by psychologists all over the world, real groups have never once been shown to be more productive than virtual groups. In fact, real groups that engage in brainstorming consistently generate about half the number of ideas they would have produced if the group’s individuals had [worked] alone.

It is hard to believe (as with any categorical statement) that this is a final verdict. Some bloggers correctly point that done right, brainstorming is a powerful tool (here and here). Mindtools.com and Wikipedia describe effective brainstorming process.

However, group brainstorming indeed has potential risks for generating less and lower quality ideas:

1. Ideas that challenge conventional wisdom are suppressed or considered mistaken
2. People can change or even disregard own ideas while listening to ideas from others, especially authoritative sources
3. Sticking with the crowd causes less willingness for risky and innovative ideas.

Effective brainstorm process avoids these problems when:

1. People investigated the topic before the meeting and come prepared with own ideas and considerations.
2. People are diverse, have different perspective and background. They bring specialized and tacit knowledge to the table.
3. People are encouraged to think independently, creatively and don’t criticize others. Everybody contributes as equal; ideas could be even presented anonymously.

I experienced myself both successful and unproductive brainstorming sessions. I found that good brainstorming session produces ideas, which are better and more than just selection from individual ideas. It is real enjoyment to see when people create ideas, enrich each other thinking and generate new wonderful and unseen ideas. A side effect is important: people consider themselves as a part of the process, feeling ownership and control. They accept final ideas readily, better understand these ideas and are committed to implement them. This is a way to become self-organizing team.

“There are very few true artists in computer programming, most are just house painters.” – Tim Bryce’s Law

Management consultant Tim Bryce doesn’t like programmers. Many programmers don’t like him either (here, here, here, here and probably in many other places).
Mr. Bryce’s view of programmers:

• programmers often bamboozle others and heighten their own self-importance
• the average programmer has a lower IQ than any other worker with a college degree
• programmers show signs of sloppiness and mental laziness
• they appear disorganized to make it difficult to judge how they are progressing on their work effort and reveal inadequacies in workmanship.
• the typical programmer often laments he/she is being overworked, underpaid, and unappreciated.
• to the programmer’s credit, they usually possess a curiosity about technological developments. However, this must be carefully nurtured by management – too much information may distract programmers from their job.

Responses on Mr. Bryce’s post (referenced above) provide many excellent points why Mr. Bryce is wrong. However, I want to comment points where he is probably right. Also I want to understand why some management consultants with more than 30 years of experience could have such view? Certainly, I reject Freudian view that an unknown programmer hurt feelings of Mr.Bryce in childhood (the main reason is that at this time the world had only few programmers and all of them are known).

Mr.Bryce’s target audience is not programmers (whose low IQ would probably prevent understanding his Theory P anyway), but IT managers and business decision makers. The underlying premise of Theory P is: “The more effectively we manage the people who program the computer, the better we can utilize the systems to support the information needs of the business”. This theory is not about live people, but about pragmatic business and lets consider the theory from this perspective. There are three points where Mr. Bryce could be partially right.

Read full post >>

Angela Duckworth and Martin Seligman research shows that both IQ and self-discipline are correlated with academic performance and GPA, but self-discipline is a much more important contributor: those with low self-discipline have substantially lower grades than those with low IQs, and high-discipline students have much better grades than high-IQ students. Further, the study found no correlation between IQ and self-discipline—these two traits varied independently.

Comments: Does this research applies for software creation? Can we say that self-discipline is more important than IQ for programming? I believe that self-discipline, emotional intelligence and control over unconscious mind are more important than IQ in programming. You cannot get anything useful done without self-discipline; however low IQ is a problem too.
My formula for the talent in programming: Talent = IQ * Self-discipline * Creativity