Slashdot Mirror

• Code Complete 2 was the most influential book I read on how to keep it simple. http://cc2e.com/
• The Pragmatic programmer taught me how to stick it to my manager and push for more time/testing: https://pragprog.com/the-pragm...
• Refactoring taught me how to clean up the code written by developers who didn't read these books. http://www.refactoring.com/
• Clean Code brings it all together. https://sites.google.com/site/...

These books provide much better information on the topic and deserve a place on your shelf alongside the GoF's Design Patterns.

I agree with the idea to study mathematics, as a useful exercise, that would in many cases benefit programmers by giving them a good mental workout, and hopefully reinforce if not expand their understanding of mathematics, logic, and reasoning.

Beyond that I would argue for the study of writing, in a natural (human-oriented) language of your choice.

Programming as a profession, and as an art, is about the meaningful expression of ideas; in a detailed, unambiguous manner that can be processed by a computer. Programming languages are tiny, simplistic, and restrictive in their ability to express ideas, and the execution of these ideas. Writing in a natural language is much more complex, particularly when you strive to remove undesired ambiguity*. The other issue is that as a professional, programming is not done in isolation. Even if you are an independent contractors, you must be able to communicate effectively with clients and users.

*) Ambiguity can be desirable in humor and poetry.

I think that any programmer can benefit from the abilities to make logically sound, comprehensible arguments in a written document; that these abilities will make them better in their ability to understand, and be understood by users, customers, or colleagues.

The argument has been made in the past by Steven C. McConnell in Code Complete, in The Pragmatic Programmer by Andrew Hunt and David Thomas, Coding Horror by Jeff Atwood, and Joel Spolsky (of Joel on Software) in his Introduction to Best Software Writing I and College Advice. And like tons of other software developers, and their managers; repeatedly.

You see, communication is the only really important aspect of software development that people really have trouble with. The rest are details and small bugs, but for really big screw-ups you need miscommunication (or greed)

As others have said or implied, the OP's question is itself incorrect. The actual question is about how to get management to buy in.

Have your management read the relevant sections of the following: (1) Steve McConnell's Code Complete, (2) Chris Sterling's Managing Technical Debt.

If management can't or won't learn these lessons, then I can't emphasize enough how correct the P, GP, and OP posts in this thread are.

There are many ways to have management terminated or shoved aside. Go to the targeted manager(s)' boss(es). Or go to the boss(es)' boss(es)' boss(es), etc. Go the board of directors. Go to the investors. Or if management has engaged in illegal activity, report them to the proper authorities, etc. However the OP goes about having his management terminated, he is morally required to do it for the long term benefit of the investors. The investors' long term interests must come first.

Modern languages have "exit for" or "break" to bail out of a loop.

If you have a triple nested loop in the same function, you should refactor the code and move the inner loops into another function.

What do you mean by "Clean Up Code"? If you have so many branches in a single function, again, refactor the code and split them into multiple functions.

See also: Code Complete

I like your comment, because I was just reading from chapter 5 of Code Complete 2nd Edition [pdf], in which Steve McConnell writes:

Dijkstra pointed out that no one's skull is really big enough to contain a modern computer program (Dijkstra 1972), which means that we as software developers shouldn't try to cram whole programs into our skulls at once; we should try to organize our programs in such a way that we can safely focus on one part of it at a time. The goal is to minimize the amount of a program you have to think about at any one time. (pg 79)

The Linux kernel is the classic example of software which no one person can, or should, have complete knowledge of every line. The kernel has long ago grown beyond even the ability for Linus himself to keep track of everything. The point is, however, that by subdividing the code, one person doesn't need to understand every line of code.

So, I think frankly you are wrong. Or at least, you are likely the wrong person to decidedly state that "the Linux Kernel is in need of a significant refactoring effort."

There are no doubt dozens of kernel hackers that have a sound understanding of all the various subsystems and how they work together. So as for judging the kernel's supposed "complexity," that's all that matters and clearly the kernel is not so complex to justify your statement.

I truly disagree with you. Having spent the best part of a year coding in Java and using the Java style with the open brace on the same line the best I can say is that I have gotten used to it. Code Complete has a section on indentation that recommends the Java/K&R style and it is one of the few sections I fundamentally disagree with. Later in the text there is a recommendation to comment closing braces with e.g. // end while (or similar) which to me highlights the problem. If opening and closing braces are vertically aligned with the controlling statement it is obvious which section of code the brace is closing (unless the code section is so long that the opening and closing braces aren't both visible in the code window but no-one codes like that any more right?).

I much prefer Allman style, and a little extra vertical spacing just helps code clarity - the days of needing to make the most of screen real-estate went out with the 80x24 green screens.

having a leading closing brace makes you have to read into the line to see what's going on. I know it's 2 characters, but when scanning code for structure, it helps to have it on a bew line.
 
You are kidding, right? No one reads one character at a time (except those with reading disabilities). We read in chunks, and it's easy to recognize that '} else {' means there is more to the if statement. Putting it on a seperate line makes it seem like a different thought, like a new paragraph does.
 
Steve McConnell's Code Complete has a good section on formatting and readability, I sugest that everyone should read it (and the rest of the book).

I've been reading Code Complete by Steve McConnell at home and he really hits the nail on the head on how do design and write good software.

He now has a second version of his book out, I highly recommend it as a study on good software.

programming in Java is like programming in C, but without the need to learn about pointers or good programming discipline.

Back to pointers. Code Complete will tell you that in languages that deal directly with pointers, 70-80% of bugs are caused by them. Now, while I totally agree that CS grads should be able to grok pointers, they should be avoided in production code if it's feasible. Disagree with me all you want, I'll choose 70-80% less bugs every time. Feel free to call me a lazy programmer. All the good ones take that as a compliment.

• At a very low level, how a computer works. What goes on inside the CPU, what a "bus" is, what memory paging is. Structured Computer Organization by Andrew Tanenbaum, Computer Architecture by Hennessy and Patterson.
• Programming Languages, should know enough about computers to be able to write a simple program in assembly, and then learn a couple "simple" high level languages e.g. Perl, Python, Ruby, followed by C, then Java (or C++), and then a not so common language (aka "languages that make you think") like Haskell, ML, Lisp, or Scheme. Plus a basic/general history of programming languages. Suggested reading: Structure and Interpretation of Computer Programs
• Software engineering. From making sure programs work, correctly, to programming in the large (not everything can be written as a 1000 line Perl script), and software development as a profession (ethics, legalities, future). Two good references are Code Complete by Steven McConnell, and The Mythical Man-Month by Fred Brooks.
• Basic electronics. Getting Started in Electronics by Forrest Mims or Lessons In Electric Circuits - Just the basics, Ohms Law and some basic ideas such as logic gates and flip flops.
  
• Enough math to be dangerous

Yes, that is true. Find the new job before quitting the old. Personal and professional growth is absolutely a part of the decision criteria for selecting and staying with a job. The fact that it has taken the original poster years to figure this out does not say anything positive about his or her drive.

Read some books. Here are some recommendations.

• The Practice of Programming by Kernighan and Pike is an all time classic. This one is my strongest recommendation.
• Is object oriented programming the next step for you? Here is a classic by Grady Booch.
• I find Martin Fowler to be a great author on next step kinds of topics for software developers.
• Are design patterns the next step for you? The original GoF book is my recommendation.
• Are relational databases your next step? My favorite book on this subject is a LAN Times Guide to SQL.
• Is the next step to be a team lead? Then you should really read Code Complete by Steve McConnell.

Read Knuth's Art of Computer Programming.

Seriously speaking, the books I've found useful (more so than Knuth, anyway) in improving my programming or software engineering skills (in no special order):

• The Pragmatic Programmer
• Code Complete
• The Art of Unix Programming
• The Practice of Programming

You'll notice that programming is not just about programming. Seeing beyond one programmer, one team, one language, one operating system, one tool, one method, one project, etc. gets you to another level.

If that is the case, then I must reverse my position. In fact, it becomes trivially easy to ship a bug free application. Simply remove or rewrite all parts of the designer's spec in such as way as to eliminate any gaps between the finished program's behavior and what is documented there for those bugs judged as too risky to remove at this time. You can move those parts of the designer's spec to a "future release" version of the designer's spec.

While resources such as Wikipedia define the term "bug" as you do, an example of a resource that takes the bigger picture view on what a bug is is Steve McConnell's book Code Complete.

• The Pragmatic Programmer
• Code Complete
• The Practice of Programming

In short, they all suggest writing readable code is more important than commenting spaghetti, but there are also good points on commenting. (Can't be bothered to copy-paste them here, though, see for yourself.)

Steve McConnell's Code Complete is an excellent source for coding standards and a good read for any developer. I don't agree with everything in the book but it is comprehensive. Ignore that it's published by Microsoft Press, it's a good one.