I just love Steve McConnell’s classic book Code Complete 2, and I recommend it to everyone in the Software ‘world’ who’s willing to progress and sharpen his skills.

Other blog posts in this series:

• Part 1 (Chapters 1 – 4): Laying the Foundation
• Chapter 5: Design in Construction
• Chapter 6: Working Classes
• Chapter 7: High-Quality Routines
• Chapter 8: Defensive programming

The benefits you can expect from using the pseudocode:

• makes reviews easier – you can review detailed designs without examining the source code
• supports the idea of iterative refinement
• makes changes easier – a few lines of pseudocode are easier to change than a page of code
• it’s easier to maintain than other forms of design documentation

Steps in building a routine

1. Design the routine
2. Code the routine
3. Check the code
4. Clean up loose ends
5. Repeat as needed

1. Design the routine

• Check the prerequisites to see that the job of the routine is well defined and fits cleanly into the overall design
• Define the problem the routine will solve
• Name the routine – good routine names are one sign of a superior program and they’re not easy to come up with
• Decide how to test the routine
• Research functionality available in the standard libraries – the single biggest way to improve both the quality of your code and your productivity is to reuse good code
• Think about error handling – think about all the things that could possibly go wrong in the routine
• Think about efficiency – in a vast majority of systems, efficiency isn’t critical. Design your routine so that it will meet its resource and speed goals
• Research the algorithms and data types – if functionality isn’t available in the available libraries, it might still be described in an algorithms book
• Write the pseudocode – you might not have much in writing after you finish the preceding steps. The main purpose of the steps is to establish a mental orientation that’s useful when you actually write the routine
• Think about the data
• Check the pseudocode – once you’ve written the pseudocode and designed the data, take a minute to review the pseudocode you’ve written. Back away from it, and think about how you would explain it to someone else
• Try a few ideas in pseudocode, and keep the best (iterate)

2. Code the routine

• Start with pseudocode
• Write the routine declaration
  • Turn the original header comment into a programming-language code comment above declaration
• Write the first and last statements, and turn the pseudocode into high-level comments

    /* Header comment about what routine does */
    Status ReportErrorMessage(
        ErrorCode errorToReport
    ) {
        //set the default status to "fail"

        //if the error code is valid, display the error message 
        //and declare success

        //if the error code isn't valid, notify the user that an internal 
        //error has been detected

        //return status information
    }

• Fill in the code below each comment

/* Header comment about what routine does */
Status ReportErrorMessage(
    ErrorCode errorToReport
) {
    //set the default status to "fail"
    Status errorMessageStatus = Status_Failure;

    //if the error code is valid, display the error message 
    //and declare success
    if ( errorMessage.ValidCode() ) {
        DisplayMessage( errorMessage.Text() );
        errorMessageStatus = Status_Success;
    }

    //if the error code isn't valid, notify the user that an internal 
    //error has been detected
    else {
        DisplayMessage( "Internal Error: Invalid error code in ReportErrorMessage()" );
    }

    //return status information
    return errorMessageStatus;
}

Each comment should normally expand to about 2 to 10 lines of code.

3. Check the code

• Mentally check the routine for errors

A working routine isn’t enough. If you don’t know why it works, study it, discuss it, and experiment with alternative designs until you do.

Compile the routine after reviewing it. It might seem inefficient to wait this long to compile. You’ll benefit in several ways, however, by not compiling until late in the process. After the first compile, you step up the pressure: “I’ll get it right with just one more compile.” The “Just One More Compile” syndrome leads to hasty, error-prone changes that take more time in the long run.

• Step through the code in the debugger
• Test the code

4. Clean up leftovers

• Check the routine’s interface. Make sure that all input and output data is accounted for and that all parameters are used
• Check for general design quality. Make sure the routine does one thing and does it well, that it’s loosely coupled to other routines, and that it’s designed defensively
• Check the routine’s variables (inaccurate variable names, unused objects, undeclared variables, and so on)
• Check routine’s statements and logic
• Remove redundant comments

Alternatives to the PPP

• Test-first development – popular development style in which test cases are written before writing any code
• Refactoring – development approach in which you improve code through a series of semantic preserving transformation
• Design by contract – development approach in which each routine is considered to have preconditions and postconditions
• Hacking? – some programmers try to hack their way toward working code rather than using a systematic approach like the PPP. If you’ve ever found that you’ve coded yourself into a corner in a routine and have to start over, that’s an indication that the PPP might work better

I just love Steve McConnell’s classic book Code Complete 2, and I recommend it to everyone in the Software ‘world’ who’s willing to progress and sharpen his skills.

Other blog posts in this series:

• Part 1 (Chapters 1 – 4): Laying the Foundation
• Chapter 5: Design in Construction
• Chapter 6: Working Classes
• Chapter 7: High-Quality Routines

Defensive-programming techniques make errors easier to find, easier to fix, and less damaging to production code.

Assertions

An assertion is a code that’s used during development-usually a routine or macro- that allows a program to check itself as it runs. When an assertion is true, that means everything is operating as expected.

Use error handling code for conditions you expect to occur and assertions for conditions that should never occur.

Design by contract

Preconditions and post conditions are part of an approach to program design and development known as “design by contract”.

• Preconditions are properties that the client code of a routine or class promises will be true before it calls the routine or instantiates the object.
• Postconditions are the properties that the routine or class promises will be true when it concludes executing.

For highly robust code, assert and then handle the error anyway.

Some experts argue that only one kind is needed. But real-world programs and projects tend to be too messy to rely solely on assertions.

Error-Handling Techniques

Depending on the specific circumstances, you might want to:

• Return a neutral value
• Substitute the next piece of valid data
• Return the same answer as the previous time
• Substitute the closest legal value
• Log a warning message to a file
• Return an error code
• Call an error-processing routine/object
• Shut down

Correctness means never returning an inaccurate result; returning no result is better than returning an inaccurate result.

Robustness means always trying to do something that will allow the software to keep operating, even if that leads to results that are inaccurate sometimes.

Safety-critical applications tend to favor correctness to robustness.

Consumer applications tend to favor robustness to correctness. Any result whatsoever is usually better than the software shutting down.

Exceptions

Exceptions have an attribute in common with inheritance: used judiciously, they can reduce complexity. Used imprudently, they can make code almost impossible to follow.

What you should know about using exceptions:

• Use exceptions to notify other parts of the program about errors that should not be ignored
• Throw an exception only for conditions that are truly exceptional
• Don’t use an exception to pass the buck – handle error locally
• Avoid throwing exceptions in constructors and destructors unless you catch them in the same place
• Throw exceptions at the right level of abstraction

Use barricades

Defining some parts of the software that works with dirty data and some that work with clean data can be an effective way to relieve the majority of the code of the responsibility for checking for bad data.

Debugging Aids

Another key aspect of defensive programming is the use of debugging aids, which can be a powerful ally in quickly detecting errors.

Be willing to trade speed and resource usage during development in exchange for built-in tools that can make development go more smoothly.

Determining how much defensive programming to leave in production code

One of the paradoxes of defensive programming is that during development, you’d like an error to be noticeable-you’d rather have it be obnoxious than risk overlooking it. But during production, you’d rather have the error be as unobtrusive as possible, to have the program recover or fail gracefully.

Here are some guidelines for deciding which defensive programming tools to leave in your production code and which to leave out:

• Leave the code that checks for important errors
• Remove code that checks for trivial errors
• Remove code that results in hard crashes
• Leave the code that helps the program crash gracefully

Being defensive about defensive programming

Too much defensive programming creates a problem of its own. Code installed for defensive programming is not immune to defects, and you’re just as likely to find a defect in defensive-programming code as in any other code-more likely if you write the code casually.

My #notes from a great #book CC 2 by Steve McConnell chapter on Defensive programming ?️ https://t.co/KnBqvEySJd

— Nikola Brežnjak (@HitmanHR) September 4, 2017

I just love Steve McConnell’s classic book Code Complete 2, and I recommend it to everyone in the Software ‘world’ who’s willing to progress and sharpen his skills.

Other blog posts in this series:

• Part 1 (Chapters 1 – 4): Laying the Foundation
• Chapter 5: Design in Construction
• Chapter 6: Working Classes

Routines are used to:

• reduce complexity
• introduce an intermediate, understandable abstraction
• avoid duplicate code
• hide sequences
• hide pointer operations
• improve portability
• simplify complicated boolean tests and
• improve performance

Functional cohesion

Functional cohesion is when a function performs one and only one operation.

Cohesions that are considered to be less than ideal:

• Sequential cohesion
  • exist when a routine contains operations that must be performed in a specific order, that share data from step to step.
• Communicational cohesion
  • occurs when operations in a routine make use of the same data and aren’t related in any other way.
• Temporal cohesion
  • occurs when operations are combined into a routine because they are all done at the same time. Think of temporal routines as organizers of other events.

Unacceptable kinds of cohesion:

• Procedural cohesion
• Logical cohesion
• Coincidental cohesion

Good routine names and length

Research shows that the optimum average length for a variable name is 9-15 characters and 15-20 for a routine name.

To name the function use the description of the return value. In object-oriented languages, you don’t need to include the name of the object in the procedure name because the object itself is included in the call.

Avoid names like: document.PrintDocument().

A large percentage of routines in object-oriented programs will be accessor routines, which will be very short. From time to time, a complex algorithm will lead to a longer routine, and in those circumstances, the routine should be allowed to grow organically up to 100 – 200 lines.

Don’t write routines longer than about 200 lines.

How to use routine parameters

Interfaces between routines are some of the most error-prone areas of the program. Here are a few guidelines for minimizing interface problems:

• Put parameters in input-modify-output order
• If several routines use similar parameters, put the similar parameters in a consistent order
• Use all the parameters
• Put status or error variables last
• Limit the number of a routine’s parameters to about seven

Psychological research has found that people generally cannot keep track of more than about seven chunks of information at once. (Miller 1956.)

The difference between function and procedure is that procedure doesn’t return a value.

You should use macro routines with care and only as a last resort.

I just love Steve McConnell’s classic book Code Complete 2, and I recommend it to everyone in the Software ‘world’ who’s willing to progress and sharpen his skills.

Other blog posts in this series:

• Part 1: Laying the Foundation
• Chapter 5: Design in Construction

Class Foundations: Abstract Data Types (ADTs)

An abstract data type is a collection of data and operations that work on that data. The operations both describe the data to the rest of the program and allow the rest of the program to change the data.
For example, if you are not using ADTs to change a bold property of text you could write something like:

currentFont.bold = true;

but a better way, which keeps the abstraction of the class, is:

currentFont.SetBoldOn();

It ain’t abstract if you have to look at the underlying implementation to understand what’s going on. ~ P.J. Plauger

By thinking about ADT, and not about classes, we are programming into the language and not programming in language.

If a stack represents a set of employees, treat the ADT as employees rather than as a stack. Treat yourself to the highest possible level of abstraction.

Try to make the names of classes and access routines independent of how the data is stored.

For example:

game.save()

is better than

game.saveDataInFile()

One way to think of a class is as an abstract data type plus inheritance and polymorphism.

Good class interface

The first and probably most important step in creating a high-quality class is creating a good interface. This consists of creating a good abstraction for the interface to represent and ensuring the details remain hidden behind the abstraction.

If the class interface doesn’t present a consistent abstraction, then the class has poor cohesion.

Class interface consists of public routines (functions, methods)

Each class should implement one ADT!

In some cases, you’ll find that half a class’s routines work with half the class’s data, and half the routines work with the other half of the data. In such a case, you really have two classes masquerading as one. Break them up!

Move unrelated information to another class

Good Encapsulation

Encapsulation is a stronger concept than abstraction.
Abstraction helps to manage complexity by providing models that allow you to ignore implementation details. Encapsulation is the enforcer that prevents you from looking at the details even if you want to.

Don’t expose member data in public

You shouldn’t expose data like this:

float x;
float y;

because client code can monkey around with data. And perfect encapsulation would look like:

float GetX();
float GetY();
void SetX( float x );
void SetY( float y );

Now you have no idea whether the underlying implementation is in terms of floats x, y, whether the class is storing those items as doubles and converting them to floats, or whether the class is storing them on the moon and retrieving them from a satellite in outer space. ?

Avoid friend classes

In a few circumstances such as the State pattern, friend classes can be used in a disciplined way that contributes to managing complexity. But, in general, friend classes violate encapsulation. They expand the amount of code you have to think about at any one time, increasing complexity.

Design and Implementation Issues

Containment (“has a” Relationships)

Containment is a simple idea that a class contains a primitive data element or object. A lot more is written about inheritance than about containment, but that’s because inheritance is more tricky and error prone, not because it’s better.

Inheritance (“is a” Relationships)

Don’t inherit a class instead it’s a truly “is a” more specific version of the Base Class. ~ Barbara Liskov

Inherited routines come in three basic flavors:
+ An Abstract overridable routine means that the derived class inherits the routine’s interface but not its implementation.
+ Overridable routine means that the derived class inherits the routine’s interface but not its implementation

Overridable routine -> polymorphism
+ A non-overridable routine means that the derived class inherits the routine’s interface and its default implementation and it is not allowed to override the routine’s implementation

Don’t reuse names of non-overridable base-class routines in derived classes.

Avoid deep inheritance trees

Deep inheritance trees have been found to be significantly associated with increased fault rates. That’s because of deep inheritance trees increase complexity, which is exactly the opposite of what inheritance should be used to accomplish.

7±2 subclasses from base class, and maximum of three levels of inheritance

Rules for inheritance

• If multiple classes share common data but not behavior, create a common object that those classes can contain.
• If multiple classes share common behavior but not data, derive them from a common base class that defines the common routines.
• If multiple classes share common data and behavior, inherit from a common base class that defines the common data and routines.
• Inherit when you want the base class to control your interface; contain when you want to control your interface.

Law of Demeter

The rule states that Object A can call any of its own routines. If Object A instantiates an Object B, it can call any of Object B’s routines. But it should avoid calling routines on objects provided by Object B.

Constructors

Initialize all member data in all constructors, if possible. Initializing all data member in all constructors is an inexpensive defensive programming practice.

Enforce the singleton property by using a private constructor. If you want to define a class that allows only one object to be instantiated, you can enforce this by hiding all the constructors of the class and then providing a static GetInstance() routine to access the class’s single instance.

Deep and shallow copy

• Deep copies are simpler to code and maintain than shallow copies
• Shallow copies are created typically to improve performance

Prefer deep copies to shallow copies until proven otherwise.

Reasons to Create a Class

Create a class to hide information so that you won’t have to think about it and to reduce complexity. Sure, you will need to think about it when you write the class, but after it’s written you can forget about the implementation details and use the class without any knowledge of its internal workings.

Key points

• Class interface should provide a consistent abstraction. Many problems arise from violating this single principle.
• Classes must have data members and behavior
• Containment is usually preferable to inheritance unless you’re modeling an “is a “relationship
• Inheritance is a useful tool, but it adds complexity, which is counter to Software’s Primary Technical Imperative of managing complexity

My #notes from the classic Code Complete 2 #book by Steve McConnell chapter 5: Working Classes https://t.co/aWK3uWdBUr

— Nikola Brežnjak (@HitmanHR) August 21, 2017

I just love Steve McConnell’s classic book Code Complete 2, and I recommend it to everyone in the Software ‘world’ who’s willing to progress and sharpen his skills.

My notes from Part 1: Laying the Foundation are here.

The second part of the book covers the following chapters:

• Design in Construction
• Working Classes
• High-Quality Routines
• Defensive Programming
• The Pseudocode Programming Process

In this post I’ll share my notes from the:

Chapter 5: Design in Construction

The Wicked problem is the one that could be defined only by solving it or solving a part of it.

An example is Tacoma Narrows bridge. Only by building the bridge (solving the problem) could they learn about the additional consideration in the problem that allowed them to build another bridge that still stands.

According to Fred Brook, there are essential and accidental types of problems.

Managing complexity is the true primary technical goal in software design.

Internal design characteristics:

• minimal complexity
• high fan-in
• ease of maintenace
• low-to-medium fan-out
• minimal connectedness
• portability
• extensibility
• leanness
• reusability

A good general rule is that a system-level diagram should be acyclic. In other words, a program shouldn’t contain any circular relationship in which Class A uses Class B, Class B uses Class C, and Class C uses Class A.

Steps in designing with objects

1. Identify the objects and their attributes
   • Computer programs are usually based on real-world entities
2. Determine what can be done to each object
   • A variety of operations can be performed on each object
3. Determine what each object can do to the other objects
   • This step is just what it sounds like. The two generic things can do to each other are containment and inheritance
4. Determine the parts of each object that will be visible to other objects
   • One of the key design decisions is identifying the parts of an object that should be made public and those that should be kept private
5. Define each object’s public interface
   • Define the formal, syntactic, programing-language-level interfaces to each object. The data and methods the object exposes to every other object are called “public interface.”

Heuristics in terms of Software’s Primary Technical Imperative: Managing Complexity.

Summary of Design Heuristics

• Find Real-World Objects
• Form Consistent Abstractions
• Encapsulate Implementation Details
• Inherit When Possible
• Hide Secrets (Information Hiding)

Information hiding is useful at all levels of design, from the use of named constants instead of literals to the creation of data types, to class design, routine design, and subsystem design.

A good class interface is like the tip of an iceberg, leaving most of the class unexposed

Ask yourself what needs to be hidden in this class?

Loose Coupling describes how tightly a class or routine is related to other classes or routines. The goal is to create classes and routines with small, direct, visible, and flexible relations to other classes and routines.

In Software, make the connections among modules as simple as possible.

Life is one big fat program which has a ton of options, but only one nonoptional parameter

The key note is that Classes and routines are first and foremost intellectual tools for reducing complexity. If they’re not making your job simpler, they’re not doing their jobs.

Design patterns

Patterns provide the cores of ready-made solutions that can be used to solve many of software’s most common problems.

• Abstract Factory
  • Supports creation of sets of related objects by specifying the kind of set but not the kind of each specific
• Adapter
  • Converts the interface of a class to a different interface
• Bridge
  • Builds an interface and an implementation in such a way that either can vary without the other
• Composite
  • Consists of an object that contains additional objects of its own type so that client code can interact with top-level object and not concern itself with all the detailed
• Decorator
  • Attaches responsibilities to an object dynamically, without creating specific subclasses for each possible configuration of
• Facade
  • Provides a consistent interface to code that wouldn’t otherwise offer consistent
• Factory Method
  • Instantiates classes derived from a specific base class without needing to keep track of the individual derived classes anywhere but the Factory
• Iterator
  • A server object that provides access to each element in a set sequentially
• Observer
  • Keeps multiple objects in synch with each other by making a third the object responsible for notifying the set of objects about changes
• Singleton
  • Provides global access to a class that has one and only one instance
• Strategy
  • Defines a set of algorithms or behaviors that are dynamically interchangeable with each other
• TemplateMethod
  • Defines the structure of an algorithm but leaves some of the detailed implementation to subclasses

Cohesion refers to how closely all the routines in a class or all the code in the routine support a central purpose

When in doubt use brute force. ~ Butler Lampson

Understand the problem – devise a plan – carry out a plan, look back to see how you did. ~ Polya George

Design practices

• Iterate
• Divide and Conquer
• Top-down and bottom-up
• Experimental prototyping
  • You have to be prepared to throw away the code (trick: name the classes -prototype-NameClass )

Put your code in a drawer. Then, come and take it out a week later, and you will criticize the fool who wrote it!

People who preach software design as a disciplined activity spend considerable energy making us all feel guilty. We can never be structured enough or object-oriented enough to achieve nirvana in this lifetime. We all truck around a kind of original sin from having learned Basic at an impressionable age. But my bet is that most of us are better designers than the purists will ever acknowledge. ~ P.J. Plauger

Key note for design is to iterate, iterate, and iterate again and after that, you will be happy with your design.

Conclusion

Hope you liked this post and that you’ve seen that this book really has a lot to offer, so I urge you to get your copy, read it and apply it!

Until next time, take care and keep on improving ?

My #notes from the #book Code Complete 2, Chapter 5 by ever so slightly magnificent Steve McConnell https://t.co/GPV0rq6Upd

— Nikola Brežnjak (@HitmanHR) August 13, 2017

I just love Steve McConnell’s classic book Code Complete 2, and I recommend it to everyone in the Software ‘world’ who’s willing to progress and sharpen his skills.

I read the book way back in 2011, took notes and wrote them down in my notebook, as I usually do:

In this notebook, I have several book notes, and the best of all of them landed on the inner pages of the covers:

Wishful thinking: one day this will be worth ???

Now, I figured I should get these good passages and quotes and my observations out to the blog for easier search in the future.

Too bad the actual books don’t come with a search functionality, right? ? Well, just get a Kindle, right? Honestly, I did and it seems like I still prefer ‘real’ books.

Anyways, in this post we’ll cover the whole Part 1: Laying the Foundation which consists of 4 chapters:

• Welcome to Software Construction
• Metaphors for a Richer Understanding of Software Development
• Measure Twice, Cut Once: Upstream Prerequisites
• Key Construction Decisions

The post which covers the chapter 5. Design in Construction is here.

So, let’s get to it, shall we?

Chapter 1: Welcome to Software Construction

Software construction is the central activity in software development. Construction is the only activity that’s guaranteed to happen on every project. The main activities in construction are

• detailed design
• coding and debugging
• integration and
• developer testing (unit testing and integration testing)

The quality of the construction substantially affects the quality of the software.

Chapter 2: Metaphors for a Richer Understanding of Software Development

An algorithm is a set of well-defined instructions for carrying out a particular task. On the other hand, a heuristic is a technique that helps you look for an answer. Its results are subject to change because a heuristic tells you only how to look, not what to find. Metaphors are heuristics, not algorithms. As such, they tend to be a little sloppy.

Treating software construction as similar to building construction suggests that careful preparation is needed and illuminates the difference between large and small projects.

From perspective of planning it’s not the same to build a doghouse or a skyscraper.

Also, a good metaphor for software construction is an oyster forming a pearl. The image is a good way to visualize incremental development or gradual change.

Thinking of software-development practices as tools in an intellectual toolbox suggests further that every programmer has many tools and that no single tool is right for every job. Choosing the right tool for each problem is one key to being an effective programmer.

Chapter 3: Measure Twice, Cut Once: Upstream Prerequisites

Be sure your preparation activities are reducing risks, not increasing them. If you want to develop high-quality software, attention to quality must be part of the software-development process from the beginning to the end. Attention to quality at the beginning has a greater influence on product quality than attention at the end. In general, the principle is to find an error as close as possible to the time at which it was introduced. The longer the defect stays in the software “food chain”, the more damage it causes further down the chain.

The overarching goal of preparing for construction is risk reduction.

Iterative approaches tend to reduce the impact of inadequate upstream work, but they don’t eliminate it. You might choose a more sequential (up-front) approach when:

• requirements are fairly stable
• little project risks
• long-term predictability is important
• The cost of changing requirements, design, and code downstream is likely to be high

You might choose a more iterative (as you go) approach when:

• requirements are not well understood
• the design is complex, challenging, or both
• the development team is unfamiliar with the applications area
• the project contains a lot of risks
• long-term predictability is not important
• the cost of changing requirements, design, and code downstream is likely to be low

Part of the programming job is to educate bosses and coworkers about the software-development process, including the importance of adequate preparation before programming begins.

Problem-Definition Prerequisite – the penalty for failing to define the problem is that you can waste a lot of time solving the wrong problem. This is a double-barreled penalty because you also don’t solve the right problem.

The 25% change in requirements results in 70-80% of reworking on the project.

Make sure everyone knows the cost of requirements change.

Requirements Prerequisite – requirements describe in detail what a software system is supposed to do, and they are the first step toward a solution. Paying attention to requirements helps to minimize changes to a system after development begins. If you find a coding error during coding, you change a few lines of code and work goes on. If you find a requirements error during coding, you have to alter the design to meet the changed requirement.

Stable requirements are the holy grail of the software development.

Architecture Prerequisite – Architecture is also known as system architecture, high-level design, and top-level design. The architecture should define the major building block in a program. Every feature listed in the requirement should be covered by at least one building block. Building block should have one area of responsibility, and the minimization of the information that blocks have about each other is needed. Architecture should specify major classes that are used.

It’s good to stick to the 80/20 rule, which specifies the 20% of the classes that make 80% of the system’s behavior.

Esential problem with large systems is maintaining their conceptual integrity.

Typical architectural components are:

• program organization
• specification of major classes
• data design
• business rules
• user interface design
• resource management
• security
• performance
• scalability
• interoperability
• internationalization/localization (I18N – Internationalization and L10N – localization)
• error processing.

The architecture should address all requirements without gold-plating (without containing elements that are not required).

I wonder when managers will start to understand that software development is more than just coding.

WISCA – Why isn’t Sam coding anything?
WIMP – Why isn’t Mary programming?

If you can’t explain something to a six-year-old, you really don’t understand it yourself.

The worst thing that can happen to you is to end up maintaining someone’s code who obviously never heard of classes, cause then you will feel like watching a foreign movie with no subtitles.

Only one subsystem/class should access database

The new design has to be easy to change without affecting business rules and program results.

The architecture should clearly describe a strategy for handling changes.

We’ve always done it that way – be wary of that statement! To this, I’d add “Do your best in trying to inform, but if management doesn’t budge, run away as fast as you can”

Bad requirements – if they are found out later, the fixing costs a lot more.

Chapter 4: Key Construction Decisions

Use a language that you’ve used before, and you will become more experienced with it and more productive

C#, C++, Java, Visual Basic – 5 to 15 times more productive than C, Assembly

Developers working in interpreted languages are more productive than the ones using compiled ones.

Most common languages:

• Ada – named after Ada Lovelace, the first programmer; used in military, space, and avionic systems
• Assembly language – assembler, low-level language, used for maximizing speed and code size.
• C – 1970 Bell Labs
• C++ – 1980 Bjarne Stroustrup
• C# – 2001 Microsoft Anders Hejlsberg
• Cobol – Common Business Oriented Language, developed in 1959 – 1961
• Fortran – first-high level computer language
• Java – developed by Sun Microsystems; runs on virtual machine
• JavaScript – primarily used for client side programming (note by me from 2017: not anymore. Node.js made sure of that.)
• Perl – string-handling language; often used for system administration tasks.
• PHP – used to access server-side interactive functions and accessing database information. Note from me: everybody seems to hate this language nowadays ?
• Python – Python is an interpreted, interactive, object-oriented language that runs in numerous environments
• SQL – declarative language, meaning that it does not define a sequence of operations, but rather the result of some operations.
• Visual Basic – high-level, object-oriented, visual programming version of Basic developed by Microsoft.

Programmers who program ‘in’ a language limit their thoughts to constructs that the language directly supports. If the language tools are primitive, the programmer’s thoughts will be primitive.

Programmers who program ‘into’ a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language.

Conclusion

Hope you liked this post and that you’ve seen that this book really has a lot to offer, so I urge you to get your copy, read it and apply it!

Until next time, take care and keep on improving ?

My #notes from all-time classic #book Code Complete 2 by Steve McConnell Part 1: Laying the Foundation https://t.co/8jpjxTgMql

— Nikola Brežnjak (@HitmanHR) August 1, 2017

I was a technical reviewer for the book Deploying Node.js:

This was done via PacktPub, and I must say that this was a great learning experience and I’m glad that I was able to help make this book better. From my experience with the project coordinator Mary Alex I have nothing but good words for them.

Finally, my name in a print book 🙂

This book covers a lot of ground like how to

• optimize your code for production
• use Docker and Vagrant
• deploy to Heroku, OpenShift and DigitalOcean
• use Nginx for load balancing
• use Redis
• use Gulp, Browserify, npm, Mocha, Chai and Sinon
• manage deployments with Git, Jenkins and Ansible

Here is the short summary of each chapter:

• Chapter 1, Appreciating Node
  • what is Node.js and where it excels
• Chapter 2, Installing and Virtualizing Node Servers
  • teaches you how to create a basic Node.js application and deploy it to Heroku, OpenShift and DigitalOcean
• Chapter 3, Scaling Node
  • shows vertical and horizontal scaling techniques among which how to use Nginx for load balancing
• Chapter 4, Managing Memory and Space
  • shows the advantages of microservices
  • shows how to use Redis
• Chapter 5, Monitoring Applications
  • shows how to effectively monitor your application once it has been deployed
• Chapter 6, Building and Testing
  • explains how to create a build workflow for your application with full examples of using Gulp, Browserify, and npm
  • shows how to do testing with Mocha, mocking with Sinon, and using PhantomJS for headless browser testing
• Chapter 7, Deploying and Maintaining
  • shows how to set up a virtualized development environment and manage deployments with Git, Jenkins and Ansible

As said, this book covers a lot of topics and, in my opinion, it is not suited for beginners in the field, but for those who have some experience with Node.js and other tools. However, it’s great that a simple introduction is given to all these topics so that one who is interested more in some particular section, can easily build upon the knowledge gained from the book. The author clearly shows how a Node.js app should be built, tested, monitored, deployed, scaled and maintained.

This book was published in May this year, but I didn’t want to write the review before, so that it wouldn’t seem to be a biased one. Since then I worked as a technical reviewer on two of their Ionic products (one book and one short video), about which I’ll post when they’ll be officially published.

Anyways, I hope this review will help nudge you in taking this book into consideration if you’re looking for how to deploy your Node.js applications.

#Technical #review of the #book #Deploying #Node.js by Sandro Pasquali https://t.co/EUi0shYmn6

— Nikola Brežnjak (@HitmanHR) December 28, 2015

I rated the book The passionate programmer by Chad Fowler as favorite on my Shelfari account and shortly reviewed it as:

Trully a classic in our field!

Those of you who have been following my Books category know that I like to mark the passages that I find valuable from books that I read (and somewhere also add my own piece of wisdom ), like for example:

All in all, below are my notes from this book (yes, I know – there are quite a lot of them), and I’m sure a lot of them will resonate with you and I’m sure you’ll want to get a physical copy for yourself  too (if for nothing else, then for doodling on it ;)). Best of all, the book is currently 43% off on Amazon for only $13.58.

I believe that everyone has remarkable in them but that it takes finding something they truly care about to draw it out. You can’t be remarkable if you don’t love your environment, your tools, and your domain.

To become remarkable, you have to believe that you’re making a significant dent in the universe.

Most people spend far more of their waking adulthood working than doing anything else.

If your life is primarily consumed by your work, then loving your work is one of the most important keys to loving your life. Challeng-ing, motivating, rewarding work is more likely to make you want to get up in the morning than dull, average tasks. Doing your job well means that the activity you do for 50 percent of your available time is something you’re good at. Conversely, if you don’t do your job well, a large amount of your time will be spent feeling inadequate or guilty over not performing at your best.

You don’t win a race by trying not to lose.

Kent Beck Extreme programming explained

A person who wants to become great is far more likely to become great than someone who just wants to do their job.

Most people follow everyone else’s plan but their own. To start differentiating yourself, all you have to do is stop and take a good look at your career. You need to be following your plan for you – not theirs.

Businesses don’t exist so we can have a place to go every day. The purpose of a business is to make money.

In The Pragmatic Programmer: From Journeyman to Master, Dave Thomas and Andy Hunt talk about programming by coincidence. Most programmers can relate to the idea: you start working on something, add a little code here, and add a little more there. Maybe you start with an example program that you copy and paste from a website. It seems to work, so you change it a little to be more like the program you really need. You don’t really understand what you’re doing, but you keep nudging the program around until it almost completely meets your needs. The trouble is, you don’t understand how it works, and like a house of cards, each new feature you add increases the likelihood your program will fall apart.

Which technologies should we invest in? Which domain should we develop expertise in? Should we go broad or deep with our knowledge? These are questions we really should be asking ourselves.

Imagine you’ve started a company and you’re developing what is destined to be the company’s flagship product. Without a “hit” with this product, your company is going to go bankrupt. How much attention do you pay to who your target customers are? Before actually manufacturing the product, how much thought do you put into what the product actually is? None of us would let decisions like these be made for us. We’d be completely attentive to every detail of the decision-making process.

So, why is it that most of us don’t pay this kind of attention to the choices we make in our careers? If you think of your career as a business (which it is), your “product” is made up of the services you have to offer. Is demand for your services going to grow or decline over the coming years?

15 years ago COBOL would be a low-rise choice. Low risk low reward. At the time if you invested in Java it would be high risk high reward. BeOS was high risk no reward at the time.

Picking a stable technology that has already wedged itself into the production systems of businesses worldwide is a safer, but potentially less rewarding, choice then picking a flashy new technology that nobody has deployed yet.

Make a list of early, middle, and late adoption technologies based on today’s market. Map them out on paper from left to right; the left is bleeding edge, and the right is filled by technologies that are in their sunsets. Push yourself to find as many technologies in each part of the spectrum as possible. Be as granular as possible about where in the curve they fall in relation to one another. When you have as many technologies mapped out as you can think of, mark the ones that you consider yourself strong in. Then, perhaps, in a different color, mark the ones that you have some experiehce with but aren’t authoritative on. Where are most of your marks on the adoption curve? Do they clump? Are they spread evenly across? Are there any technologies around the far edges that you have some special interest in?

As a .NET programmer, you may find yourself competing with tens of thousands of more people in the job market than you would if you were, for example, a Python programmer. This would result in the average cost of a .NET programmer decreasing significantly, possibly driving demand higher (in other words, creating more .NET jobs). So, you’d be likely to find jobs available, but the jobs wouldn’t pay all that well. If the Python job market were to support noticeably higher prices per programmer, additional people might be attracted to supply their services at this higher price range, resulting in competition that would drive the price back down.

India caters to the already balanced IT services markets. You don’t find mainstream Indian offshoring companies jumping on unconventional technologies. They aren’t first-movers. They generally don’t take chances.

You can’t compete on price, but you can compete on ability.

Research current technical skill demand. Use job posting and career websites to find out which skills are in high demand and in low demand. Find the websites of some offshore outsourcing companies (or talk to employees of those companies if you work with them). Compare the skills available via these companies with the high—demand list you compiled. Make note of which skills appear to be in high demand domestically with little penetration offshore. Do a similar comparison between bleading—edge technologies and the skills available via offshore outsourcing firms. Keep your eyes on both sets of technical skills that are underserved by the offshore companies. How long does it take for them to fill the holes (if ever)? This time gap is the window during which a market imbalance exists.

If you want to stay relevant,you’re going to have to dive into the domain of business you’re in.

Look for industry websites that you can monitor on a regular basis. In both the websites and the magazines, pay special attention to what the big news items and the feature articles are about. What is your industry struggling with? What’s the hot new issue right now? Whatever it is, bring it up with your business clients. Ask them to explain it and to give you their opinions. Think about how these current trends affect your company, your division, your team, and eventually your work.

Be the worst guy in every band you’re in. Being the worst guy in the band means always playing with people who are better than you.

So I learned from this that people can significantly improve its regress in skill, purely based on who they are performing with.

Pick an open source project that you admire and whose developers appear to be at that “next level” you’re looking to reach.

At the time I’d writing, the most popular language is Java, followed by C.

My explanation is that either good people seek out diversity, because they love to learn new things, or being forced into alien experiences and environments created more mature, well-rounded software developers.

For me, as a hiring manager, the first reason is that it shows that you’re interested. If I know you learned something for the sake for the sake of self-development and (better) pure fun, I know you are excited and motivated about your profession.

Learn a new language that makes you think in a new way.

Thinking about not losing is not the way to win! Winners take risks. They think about where do you want to go – not where the rest of the pack is.

But if your job isn’t fun, as we’ve come to realize, you don’t do a fantastic job at it.

More of us understand action leads to excellence. And without fun, there’s unlikely to be any passion in a software job.

Staying in the single company, working your way up the ranks, easily would think environment in which to grow as a developer. Gone are the days of the life for who would join a big company and settle in for a full career. This sort of behavior used to be assigned of the dictation. No it’s a liability. If you work in only one place and seen one set of systems, many [smart] managers would see that as a strike against you when making hiring decisions. I personally rather hire someone who has seen the variety of successes and failures in different environments than someone who has known only one way of doing things.

Programmer geeks can’t lead, and leaders can’t hack. It’s rare to find someone who’s even decent both.

Unfortunately, the software industry has turned out a whole lot of these shallow specialists who use the term specialist as an excuse for knowing only one thing.

This guy wanted to build his career around a specific technology created by a specific company of which he was not an employee. What if the company goes out of business? What if it let its now-sexy technology become obsolete? Why would you want to trust a technology company with your career?

The professional services barrier is the artificial barrier that a company erects between you and the solution to a problem you may have so that it can profit from selling you support services. Sometimes this barrier is intentionally erected, and sometimes it’s erected as a side effect of the attempt the company makes to protect its intellectual property (by not sharing its source code).

Try the small project, twice. Try it once in your home-based technology and then once, as idiomatically as possible, in the competing technology.

You have to be passionate about your work if you want to be great at your work. If you don’t care, it will show.

It turns out that, coupled with my natural talent, a few hours of investment have made these ”always wanted to be able to do it” abilities attainable. And as I’ve started to put in the investment, it builds on itself. One technique leads to the next, and one barrie-breaking practice session motivates the next. The structured me who invests in his abilities (even as a hobby) completely wipes the floor with the me who bets it all on natural talent and ability.

Lao Tzu said, ”Give a man a fish; feed him for a day. Teach a man to fish; feed him for a lifetime.” That’s all well and good. But Lao Tzu left out the part where the man doesn’t want to learn how to fish and he asks you for another fish tomorrow. Education requires both a teacher and a student.

Don’t ask to be taught, learn for yourself!

You can creatively help a business until you know how it works.

Depending on others is often seen as a sign of weakness.

It’s better to be moving in one direction than to be sitting still.

Important thing is that he narrowed down the long list of skills I could be learning to the short list of skills I learned.

If you want to really learn something, try teaching it to someone.

You don’t have to set up a formal mentoring relationship to get these benefits. Just start helping people, and the rest will come naturally.

If you always sound good during practice sessions, it means you’re not stretching your limits.

Important thing is to find your practice needs and to make sure you’re not practicing during your performances [on the job]. You have to make time for practice. It’s your responsibility.

codekata.com

Even with the abundance of prescriptive methodologies to choose from, it’s not likely you will ever work for a company that fully implement any of them. That’s OK. The best process to follow is the one that makes your team most productive and results in the best products.

Studying the work of masters is in the central part of becoming a master.

If you can hear the music or see the piece of art, you can learn from it. Thankfully, as a soft for developers we have access to practically infinite array of existing software in the form of open source software.

Sir Isaac Newton said, “If I have seen further, it’s by standing on the shoulders of giants.”

The standard IT management answer is that you add programmers to go faster. It’s wrong, but that’s what people believe.

Unless you’re really lucky, you’re probably not getting paid to be smart.

We are being paid to create value.

To be successful, wrong ability will get you only so far. The final stretch is populated by closures – people who finish things. This means getting up out of our reading chairs and getting things done.

Work expands so to fill time available for its competition.

Sense of urgency, even if manufactured, is enough to easily double or triple your productivity.

Always be the one to ask, “But, what can we do right now?”

It seems backward, but keeping your mind focused on the present will get you further toward your goals than keeping your mind focused on the goal itself.

Why is that, without facing great pressure, we are often able to work ourselves into this kind of altruistic, ultra productive frenzy.

How much more fun with your job be if you could treat the most interesting and annoying tasks with the same feverish desire to do them right?

It’s easy to get into the mode of just wanting more. It unfortunately seems to be a basic human tendency, in fact. You get the salary increase, and it feels good for a little while, but then you’re thinking about the next one.

Ask, “Was I worth it today?”

A dollar today is worth more than a dollar next year, because a dollar today can be used to generate more dollars.

You should never get too comfortable.

The less replaceable you think you are, the more replaceable you are.

Everyone likes creating. That’s when we feel we are given the opportunity to really put our stamp on a piece of work. To feel like we own it.

If l give you $1,000 and ask you to go get me a cup of coffee, I’m going to be very unhappy if you return with 1,000 less dollars and no cup of coffee. I’m even going to be unhappy if you bring me plenty of really nice coffee but it takes you two hours. If I give you $0 and ask you to go get me a cup of coffee, I’ll be extremely appreciative if you actually return with the coffee, and I’ll be understanding if you don’t. Project work is like the first scenario. Maintenance is like the second.

Martin renamed 40 hour work week to 8 hour burn.

When it comes to work less really can be more. The primary reason cited by the extreme programmers is that when we are tired we can’t think as effectively as when we are rested. When we are burned out, we aren’t as creative, and the quality of our work reduce his dramatically. We start making stupid mistakes that end up costing us time and money.

Projects are marathons not sprints.

Though your short-term productivity will significantly increase as you start putting in the hours, in the long term you’re going to crash so hard that the recovery time will be larger than the productivity gains you enjoy during your 80 hour weeks.

Apparently, when money was scarce, I found ways to be more efficient with my cash. And, the end result was essentially the same.

Bob Martin’s eight hour burn places the constraint on you and gives you a strategy for dealing with that constraint. You get to work and think, I’ve only got eight hours!

As thought workers, even if we’re not in front of a computer or in the office, we can be working. You might be working while you’re driving to dinner with your spouse or while you’re watching a movie. Your work is always around nagging you.

Make sure you sleep well tonight. Tomorrow, eat breakfast and then start work at an exact time [preferably a little earlier than usual]. Work on it for four hours. Take an hour lunch. Then work for four more hours so intensely that you’re absolutely exhausted and can’t do anymore work. Go home, relax, and have fun.

A problem needs resolution. Lingering on who’s fault it is only prolongs the issue.

The quickest path to missing your commitment is to make commitments that you know you can’t meet. I know that sounds patently obvious, but we do it every day. We are put on the spot and we don’t want to disappoint our leaders, so we agreed to impossible work being done in impossible timelines.

Heroes never panic.

We panic because we lose perspective. When something is going wrong, it’s hard not to focus all attention on the problem. To some extent, that’s a good way to solve problems. Unfortunately, it also makes the problem, no matter how small, see more important than it is. And with the problem inflated and stress level running high, our brains turn themselves off.

So, here’s how I’m learning to not panic. When something bad happens and I start to feel that sinking, stressed-out feeling that leads to panic, I compare myself to the frustrated computer-illiterate, and I laugh at myself. I analyze the situation from the third—person perspective, as if I’m helping that frustrated family member with their word processing disaster. Seemingly hard problems are suddenly easier. Seemingly bad situations are suddenly not so bad. And, I often find that the solution simple and staring me in the face in the same way that an error dialog often tells you exactly what to do next. If you’d just have the presence of mind to read the error message, the problem might be solved.

Like families, successful projects are alike, but they become successful project fails in its own way.

In short, you may have the best product in history, but if you don’t do some kind of advertising, nobody’s going to buy it.

These managers and customers we are talking about have a dirty little secret: they are afraid of you. And for a good reason. You’re smart. We speak a cryptic language they don’t understand. You make them feel stupid with your sometimes sarcastic comments [which you might not have even intended to be sarcastic]. And, your work often is the last and most important toll gate between the projects conception and it’s birth.

Wouldn’t you want to hire the person who wrote the book and technology or methodology you’re attempting to deploy?

You will never feel 100% ready, so might as well start now.

Anyone can use Rails. Few can say Rails contributor.

Don’t just mastered the subject – write the book on it. Write code generators that take what used to be a one week process took a five minute process. Instead of being respected among your coworkers, become your cities most recognizable authority on whatever technologies you’re focusing on by doing seminars and workshops. Do something previously unthinkable on your next project.

Carve out weekly time to investigate the bleeding edge. Make room for at least two hours each week in order to research and get the colleges and to start develop skills in them.

The next time you have to wash the dishes, don’t wash them to get them done. Try to enjoy the experience of washing the dishes. Don’t focus on finishing them. Focus on the act of washing them itself.

Watch the alpha geeks.

If you’re constantly exposed to something, it’s hard to see it changing unless change happens rapidly.

Developer, review thyself.

Start keeping a journal. It could be a blog or a personal diary. Write about what you’re working on, what you’re learning, and your opinions about the industry. After you’ve been keeping the journal for sometime, reread old entries. Do you still agree? Do they sound knees? How much have you changed?

Make your improvements small and incremental but daily.

I highly recommend that you check out the book Soft Skills by John Sonmez if you liked this post, as you’ll find even more great content about how to become the best software developer version of yourself.

[18.09.2015] edit: I honestly can’t believe it! This awesome book is now also available as an audiobook! Now I’ll be able to listen to this ever so slightly awesome content even in my car! John Sonmez, congratulations!, this is probably the first ever programming related book to be published as an audiobook!

I reviewed the book Soft Skills: The Software Developer’s Life Manual by John Sonmez with 5 stars on Amazon with the following comment:

I believe Soft Skills will indeed become every software developers’ life manual, in a similar way as Code Complete 2 is.

I really enjoyed the book, and am recommending it to all my “IT” friends (just lent it today to a co-worker :)) – John Sonmez really poured his whole life experience into this, and for this I thank him since I think we all have something to learn from a man who made almost 50 courses for Pluralsight, wrote a bestseller, retired at 33, was a fitness model, bodybuilding contestant, and who is, well, just pure awesome. Btw, I also found that he’s damn speedy in answering any emails, so kudos for not being a hot headed superstar author as some these days play out to be.

The book is divided in 7 chapters, and it’s packed with awesome content. Those of you who have been following my Books category know that I like to mark the passages that I find valuable from books that I read, like for example:

but here I won’t be putting them online since that would be a whole lot portion of the book, and I don’t want to be chased for some copyright issues . Instead I’ll just show you the images of the chapters and comment a bit about them.

In the first section John talks about topics concerning ones career and steps to take in order to make the most out of it. Topics ranging from how to hack the interview, how to actually set goals, work as a freelancer, and even how to quit your job.

In the second section John talks about how to create your blog as a first thing you should do to start marketing yourself. John also has a free email course on how to build a successful blog, so make sure to get that free resource if you’re into starting your own blog, or increasing the views of your existing one.

In the third section John talks about why is continuous learning something you signed up for the minute you decided to make programming your calling. Also, he explains his own 10-step process for learning, which he used to learn and produce almost 50 courses on Pluralsight.

In fourth section John talks about methods and techniques he uses in order to stay crazily productive as he is. Few of them are KanbanFlow and Pomodoro technique.

In the fifth section John shares his own method of how he retired at the age of 33. He seems to be highly influenced by authors such as Robert Kiyosaki, and you can see my notes from his book Rich Dad Poor Dad.

In sixth section John talks about the importance of fitness in developers life as a tool for increased productivity and better well-being. Also, he covers few of the tech gear for geeks like me (I love my FitBit).

Section seven is all about having the right mental attitude, and I’ll quote one of my favorite authors, Napoleon Hill: “You can do it if you believe you can”. If you’re interested, you can read more Napoleon Hill quotes from my notes from his book Think and Grow Rich.

After the book I went on to check out his http://simpleprogrammer.com blog, and what’s awesome is that he gives a free email course on how to build a successful blog. Am currently on week 5, and am really learning some key things on what one should do in order to increase his blog credibility and, well, views. So, hope to see those 100k+ users monthly soon 😉

My notes from the book Progwriter [programmer + writter] by Azat Mardan:

It’s better to have fewer features with no bugs than lots of features with bugs.

Marketing is easy when you think about the value that you bring to other people. Think about how much frustration, and how many sleepless hours, other developers can avoid by reading your books! If your product is good, this is exactly what will happen.

Leanpub, Gumroad worth checking out. Simple webhosting via Github pages, and a lot more awesome content…

I actually liked this book very much, so that I wrote the short review (5/5) on Amazon:

Honestly, so much acquired knowledge presented in a straight forward way, one would have to spend years in trying it out himself. Great eye opener for all those who aspire to become a programming writer = progwriter.