Thread: How you guys learn programming?

Originally Posted by xeon321

Yeah, it is fun when you're cracking your head to figure out how to solve problems. But too bad, most of the 'problems' are self-imaginary(in my case, validating user input). And after writing the program, cracking your head AGAIN to think up of an even better & efficient solution

Personally, I generally enjoy that process of cracking the head to figure out how to solve problems. But that's because I love learning new stuff, and doing things I haven't necessarily done before.

The thing that a lot of people forget is that software development - if it is done right, and particularly if it is "advanced" - includes a lot of creative and exploratory problem-solving activity, rather than just (at the risk of mixing metaphors) following a cookbook process to recreate wheels. And it is the creative and exploratory processes that I enjoy, whether it is in design, coding, or debugging.

The key to being a really good developer is to embrace the creative and exploratory processes, not to avoid them.

Unfortunately, a few too many product designers and project managers view software as a cook-book activity (in other words, they expect to tell the developers what to do, and expect them to just translate directions into code). But, if you can get product designers and project managers who engage the software people in the creative process, the job is more satisfying, and the products produced also tend to be a lot better.

Originally Posted by xeon321

Couldn't really blame them, since it is not one man's job. If each team members coding in their own will , the program gonna be real messy when added together.

I think you're misunderstanding my point. I'm not arguing for anarchy. The team needs to work in a systematic manner, follow appropriate design and coding guidelines, etc etc. But those need to shape creativity, not eliminate it.

Originally Posted by xeon321

Creativity is individual, thus not all shares it.

Every individual is creative in different ways. A team of creative people, however, will not be creative unless all of the individuals within it work toward a common goals. It will also be less creative if creativity of some team members is suppressed.

The phenomenon I argue against is people in certain roles (project manager, system architect, product designer, etc) insisting that the only creative work is done by them, and all the software guys have to do is build what they are told to.

Originally Posted by xeon321

But following a cookbook process is a process where every programmer went through together. It will be easier for them I guess.
Just my thought based on what the lecturer has taught me about being a lead/manager.

As I said above, I am not arguing for anarchy. There are always certain processes, policies, and standards that need to be adhered to.

However, there is more to being a leader or manager of a software team than dropping a set of coding standards, a gant chart, and a set of directions on the table, and expecting the programmers to "just code it up". That sort of approach, which is VERY common in the industry, tends to result in unproductive and grumpy programmers.

Sometimes there is not flexibility of choice. For example, in safety critical system development, it is often necessary to follow restrictive processes and produce certain documentary evidence that the system design and implementation provides appropriate mitigation of hazards. But, put arbitrary constraints on a team without a good reason, the creativity will be stifled.

One of the constraints often put on a team is that the software guys are denied necessary creative opportunity by other team members who deem the creativity to be their territory.

Originally Posted by xeon321

Hmm, in your opinion, why would the project managers/leaders restrict the software developers?

Human nature.

People put in positions of authority often like to exercise that authority. Sometimes they do that by constraining others. Pure power game.

A lot of project managers or team leaders have not been in the trenches of software development. They have learned basics of some language or process in a course somewhere and assume that means they know all of it .... so they don't accept deviations from their way of business.

Sometimes it is fear of the unknown. Letting a team go ahead with the creative elements of the job makes it difficult to measure progress. That makes it hard to report progress to stakeholders who hold the purse strings (accountants, CEO's, clients, etc). This causes managers and leaders, whether they have experience with software or not, to suppress creativity of their teams because that is the path of least resistance.

I remember one project manager for a very complex technical system who took pride in the fact he had no knowledge of "ones and zeros" (his description of the details that he described as too low level to be relevant to anyone). That project failed in a spectacularly expensive manner after the project manager was promoted.

Customers of a software development team are often only interested in the externally visible behaviour of the software (GUI, the actions of devices the software controls, etc). They have no interest in the details of HOW the software achieves those visible things.

There are many other reasons. Also bear in mind that - contrary to what a lot of managers claim - management is not the same thing as leadership. Management is about managing resources and measuring progress toward outcomes. Leadership is about motivating people.