Code Complete: A Practical Handbook of Software Construction, Second Edition

Author: Steve McConnell
4.6
All Stack Overflow 109
This Year Stack Overflow 6
This Month Stack Overflow 1

Code Complete: A Practical Handbook of Software Construction, Second Edition

4.6

Review Date:

Comments

by maynman   2019-01-15
Speaking from a software engineering perspective, here are a few that I found really valuable. I've seen them recommended by people I respect on many occasions.

Code Complete by Steve McConnell https://www.amazon.com/Code-Complete-Practical-Handbook-Cons...

The Mythical Man Month by Frederick Brooks https://www.amazon.com/Mythical-Man-Month-Software-Engineeri...

by anonymous   2019-01-13

From the looks of it there might be multiple things you can do to make things better, depending on your context.

But first, you need to know that management is a process, not a task, and it cannot be done only on "projects in progress". It starts way prior to that, with how you initiate a project, how you plan it, then you execute it (including analysis, design, programming, testing) and close it properly. Also, you need to monitor and control the project throughout. Missing the planning step and just focusing on already started projects will not yield positive results as you're already missing some vital steps. On the other hand, it seems to me that you might not have the proper development process, and tools/infrastructure and the programming culture within the team might be lacking.

Keep in mind there are some assumptions in my writing, so you decide what's useful, as you surely know your context better. Here are my 2 cents:

  • Establish and follow a software development process. Sounds to me that you may not have a well-established process on your side. There is no short answer to this, but as a minimum I highly recommend reading Software Project Survival Guide by Steve McConnell for a pragmatic approach to managing software projects. If you want something more modern it's a good idea to look into Scrum and Kanban after that. If you really want to go deep and understand all the facets of proper project management - read the PMP Exam prepbook for how a project (any sort of project) is generally managed. It is an exam preparation book but offers a nice condensed summary on the most crucial topics. It's the hardest path, but offers the greatest benefit. Be sure to read it last, as you might find it too complex if you start with it.

  • Establish good programming culture - it's important all people on the team to have proper working habits regarding programming. Another book by Steve McConnell is the undisputed classic here Code Complete: A Practical Handbook of Software Construction, 2nd Edition. Although a bit outdated, it contains huge amount of wisdom and will help you have the basis to then start researching on how to establish a modern continuous integration/continuous delivery environment. I also liked "The Pragmatic Programmer", but I am not sure how well it aged.

  • Use software tools that will help you with organizing your work and make it much easier to track what happens. Some examples of such software:

    • Trac is a minimalist software to track progress on issues, tasks and such, and it is also free.
    • Microsoft VSTS and also the Atlassian's suite offer much deeper solutions that help in establishing a full DevOps environment. They are paid through.

Hope that helps!

I know you probably expected a simpler answer, but the hard truth is that it would probably prove to be a long and tough journey. Good results always require persistence and hard work and there are rarely shortcuts.

by anonymous   2019-01-13

As an alternative to @Sweeper's answer, consider using the Arrays.copyOf() method, as suggested in this answer. Note that the copyOf() method is type-safe whereas the clone() method isn't.

double[] a, b, c;
c = Arrays.copyOf((b = Arrays.copyOf((a = new double[10]), a.length)), b.length);

But again, I'll reiterate as @Sweeper does, that this code really smells and you should consider doing it in multiple lines. As Steve McConnell says in Code Complete 2nd Ed., the Primary Technical Imperative of software is to manage complexity (i.e. make your code simple). This doesn't necessarily mean reducing the lines of code, but more to do with enabling people who read your code to understand what it does at a glance.

by anonymous   2019-01-13

Facts:

1. GIT and other version controls systems treat white-space differently

Based on my experience, we faced on our projects: GIT and other version controls systems treat invisible spaces + TABS differently, and it leads to changes in lines, which actually haven't been affected. It's easy not to notice, when there will accidentally added one space + TAB = indent looks the same in IDE, but GIT will make the difference when merging. It damages your ability to effectively compare revisions in source control, which is really scary. It never going to happen when you are having spaces only.

2. Neutralize difference in collaborator's environment (Editor, OS, preferences, etc.)

The tab width (in spaces) depends on your environment (text editor, OS, preferences, etc.), but the space width is the same everywhere. IDEs are smart enough to treat white spaces up to you personal taste, but the output generated for collaboration should be up to standards.

3. Developers who use spaces make more money than those who use tabs

Using spaces instead of tabs is associated with an 8.6% higher salary. Using spaces instead of tabs is associated with as high a salary difference as an extra 2.4 years of experience. (source: Stack Overflow 2017 Developer Survey).

4. Numerous studies on coding style importance

If every collaborator on your project would keep the same standards on coding - it will be good in long run, collaboration is more efficient and professional, the same indent when you refactor or develop. Studies regarding that:

  1. For example, Ben Shneiderman confirmed this in Exploratory experiments in programmer behavior:

    when program statements were arranged in a sensible order, experts were able to remember them better than novices. When statements were shuffled, the experts' superiority was reduced.

  2. An old 1984 study by Soloway and Ehrlich cited in Code Complete, and supported studies from The Elements of Programming Style:

    Our empirical results put teeth into these rules: It is not merely a matter of aesthetics that programs should be written in a particular style. Rather there is a psychological basis for writing programs in a conventional manner: programmers have strong expectations that other programmers will follow these discourse rules. If the rules are violated, then the utility afforded by the expectations that programmers have built up over time is effectively nullified.

by anonymous   2019-01-13

I think that in cases involving performance optimization, you really want to create an A/B test to determine which one you should do. There really is no cookie cutter answer for image preloading that applies to everybody as a best practice.

One of the biggest tenets of a favorite book of mine, Lean Enterprise, is use to A/B tests to prove or disprove a HIPPO (highly paid person's opinion). Certain opinions carry a lot of weight, both in your organization and on the internet. Because of their importance and reputation, their opinions veer towards the realm of fact, even though it may not be.

The practice of measuring performance empirically is also touted by another book I love which deals with performance tuning - Code Complete 2nd Ed. In that book, McConnell gives several code examples where you would expect one piece of code to be optimal, but in fact, it performed poorly (see chapters 25 and 26). One of his key points is that you should always test a performance optimization. If it isn't worth testing, it isn't worth writing the "highly performant" code in the first place. McConnell's premise doesn't just apply to his low level coding examples, but to high level decisions such as preloading images above the fold as well.

I can also attest to the importance of A/B testing at a professional level. I used to work on Amazon's SEO team and we A/B tested everything. The fact of the matter is that you never really know how customers will respond to something. Nobody can predict customer behavior - not even Jeff Bezos - and you really need to back up your hypothesis with real data to prove or disprove the validity of what you're doing.

Even though you can find multiple blog articles and online sources discussing whether preloading is better or not, you don't really know whether that will work for you until you've done it. Different people have different servers with different performance characteristics and different network topologies, etc. You just don't know which way is better for you until you have the data. If you launch your A/B test and find that find that your repel rate goes up when preloading, then you know that you have to dial back your treatment and return to your control. If however, you find that customers don't get bored waiting and click through at a higher rate than before, then you have a winner and you dial up the treatment - deleting the control code entirely after a period.

I hope that helps.

by ToFab123   2018-12-26
You could refresh your memories from the time before you started to complicate stuff by reading (or rereading) the marvelous book "code complete"

https://www.amazon.com/Code-Complete-Practical-Handbook-Cons...

by PiggySpeed   2018-11-10

If you want to improve your writing skills, you have to read good books and regularly practice good writing.

Read *good * coding techniques.

If you're just writing the same code you wrote the week before, you're not improving.

by samort7   2018-11-10

For anyone looking for general book suggestions, I always recommend they go with the classics:

EDIT: Updated with some more books I forgot initially, and links to the latest versions

General Computing

Computer Science

Software Development

Case Studies

Employment

Language-Specific

C

Python

C#

C++

Java

Linux Shell Scripts

Web Development

Ruby and Rails

Assembly