0. Introduction

Computer science is no more about computers than astronomy is about telescopes.
— Fellows/Dijkstra 

So, you’re a Computer Science (CS) or Electronic Engineering (EE) major at university, or perhaps a self-taught/autodidact programmer, who wants to learn more about software engineering and project management. If you’ve done any reading at sites where software development is discussed by professionals, you’ve realized there’s a lot more to learn. Unit tests, sprints, and feature branches, oh my! , are just a few of the terms that may still look and sound Greek to you…


Fig. 1 The Big Fat Academy of Athens, courtesy Wikipedia .

In fact, unless students have interned at a software company, most will complete their programs unprepared to work in industry as software engineers—not without further training. While this is often surprising to students and business folks alike, the reason is not a failing of the curriculum, but rather a common misconception.

Computer Science is a large body of study focusing on logic, algorithms, and efficient processing of information. It contrasts with Software Engineering (SE) in the same way that other theoretical vs. applied sciences do, such as how Math lays the groundwork for Physics and Applied-Physics. SE also overlaps disparate subjects such as Project Management and Quality Assurance.

Engineering is what happens when you take science and economics and try to put them together.
— Greg Wilson 

By analogy, imagine a mathematician going to work to build a line of say, MRI  scanners. Few would be surprised about the need for additional training under the circumstances. One couldn’t have mastered the multiple disciplines necessary to excel at the job immediately out of school.

Poor Naming

Our conviction [is] that "computer science" is not a science and that its significance has little to do with computers.
— Abelson/Sussman, Preface, "Structure and Interpretation of Computer Programs" 

The awkward name “computer science” in English is another source of confusion. As Mr. Fellows notes at the top of the chapter and Abelson here, CS is about the theory of computation, and only tangentially about hardware. “Computation Science” would have been a better name, which in fact it is in several Latin-based languages (e.g. Ciência da Computação  in Portuguese). This misnomer exaggerates the misconception as to what CS actually is, especially among business folks.

Academia and Industry

Scientists must keep up to date with the latest research. Engineers must be familiar with knowledge that has already proven to be reliable and effective.
— Steve McConnell 

Academia, for better or worse is focused on research and teaching, not necessarily job training. For their part, many students are choosing a foundational yet less-optimal major for prevailing work in the industry, perhaps not yet realizing the difference. A software engineering major may not even be available at some schools (though prevalence is increasing).

Lumbergh:  “Did you see the memo about this?”  

Another truth is that the majority of development jobs in industry don’t exercise CS skills, and rather are devoted to the maintenance of line-of-business “CRUD”  apps at shops not unlike Initech.  Don’t let that get you down though, there’s still a huge number of opportunities  for those looking for something different—the type of person that might read a book such as the one currently under your nose.

See also:  Software Engineering, Not Computer Science

An agreeable discussion on CS vs. SE can be found in Steve McConnell’s Book, Professional Software Development   (Ch. 4 ).

Note:  Despite sharing most of its title with this book, there’s a largely different focus. McConnell waxes philosophical, concentrating on the improvement of project outcomes through promotion of traditional engineering practices and certification.

See also:  Particle Fever

Particle Fever  is an engaging documentary , that illustrates the split between theory and implementation, while covering the first round of experiments at the Large Hadron Collider at CERN.

0.1. Purpose

Nobody would be surprised if you told them it was hard to do open heart surgery. OK, fine, so maybe software isn’t open heart surgery. But it has about the same number of moving parts, it’s probably just as complicated, and it’s critical in a different way. But there’s something weird about designing software specifically: Everybody thinks they know how to do it, even when they have no training. They just think, 'Oh sure, I can do that!'
— Joel Spolsky, Blogger/co-founder StackExchange 

As a student of computer science and programming, you’ve learned a significant portion of what you need to know as a rookie professional. The most difficult parts perhaps, but far from the “whole enchilada.” This book is meant to fill in the gaps in knowledge needed for workaday software projects. It aims to teach “in a nutshell” , the myriad subjects the pro-developer should know. It covers the material in a broad manner from theory to practice, attempting to provide a platform for further study and a “mental-map” to place subjects into context.


Fig. 2 “Computering” subjects, courtesy @jschauma  (Programing ≅ Software Engineering).

As a consequence, Project Management and Quality Assurance professionals may also appreciate the concise overview of the software engineering process that is described here; in order to learn more about how the “sausage is made.” Seasoned pro developers should also find sections of interest, as the author certainly learned a few new tricks in their writing.

…chance favors only the prepared mind.
— Louis Pasteur 

Despite an economy of words, this book provides numerous references and links to the most important books, papers, videos (and comics) available to deep-dive on subjects a reader might find compelling. Look for the “ See also” boxes (you’ve already encountered) at the ends of sections to find these resources. Nevertheless, it’s recommended that the reader plow ahead and finish this book before moving on to deeper study, as most assume an intermediate level of knowledge. Also due to their depth, many pieces will be of more use once a few years of experience have been had—bringing them to life from the seemingly theoretical.

Gluttons for Punishment?

From the book Code Complete (Ch. 35), Steve McConnell chimes in:

…a lot has been written about effective software-development practices. Much more information is available than most people realize. People have already made all the mistakes that you’re making now, and unless you’re a glutton for punishment, you’ll prefer reading their books and avoiding their mistakes to inventing new versions of old problems.

0.2. There’s “No Silver Bullet”


In folklore, a silver bullet  is the one thing that can kill a werewolf.


Fig. 3 AAUU-OOO³! courtesy 

On the other hand, a preemptive warning—the forthcoming techniques you’ll read about for improving the development process are less than foolproof. They’ll display varying degrees of success depending on numerous factors that are hard to predict with or without experience. Many circumstances will be out of your control.

Further, there’s nothing new on the horizon to make software development significantly easier than it is—and so only evolutionary advances and hard work should be expected in the near future. Several decades ago, Fred Brooks  wrote an important essay on the subject, “No Silver Bullet — Essence and Accidents of Software Engineering,” containing this mildly controversial conclusion:

There is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, or in simplicity.
— Frederick P. Brooks, Jr. (1986) 

Despite rapid change in the industry over the years, this realization has stood the test of time, including visits from a hot tub time machine. 

Also, little you’ll read in the following chapters or development blogs is applicable 100% of the time. Advice should invariably be qualified, i.e. “technique X works well with large teams that…” Often when new developers learn a technique, they’ll want to apply it everywhere, even when inappropriate. Different projects require different approaches, and your job as an engineer will be to choose from the most suitable among them.

0.3. Rounding Out Your Education

I'd tell you a UDP joke, but you might not get it…
— Anonymous

To ensure we’re on even footing, let’s go over the list of Information Technology (IT) , CS, and assorted subjects you should know to reach pro-level. If you’re self-taught or skipped a class or two, you’ll want to review the following as your minimum knowledge base:

Information Technology:
Computer Science & Programming:
  • Math & Algebra

  • Number Systems: binary and hexadecimal

  • Common Data Structures

  • Algorithms   

  • Performance characteristics and big-O notation   

  • Pointers, recursion

  • A high-level language, such as Java, ECMAScript, or Python

  • A low-level language: C

  • Build tools, such as make or similar

Now yes, you may squeak by without a few of these. Many code-monkeys have survived on fewer skills, picking things up as they go. However, as this book is focused on creating Professional Software Developers™ you’ll need the above as a foundation to that end.

If you’re still in-progress on that journey, it’s ok to keep reading. There won’t be demand here for the subjects listed above; just note that you won’t survive future developer interviews without them.

See also:  Online Resources/Books

0.3.1. Additional Subjects

Listed below are optional but cheerfully recommended additional subjects to explore. One or more may be required depending on which field of the ginormous software industry you’d like to break into:

  • Assembly language

  • Compilers

  • Computer Architecture

  • Concurrency

  • Database theory & SQL

  • Distributed system design

  • Finite state machines

  • Functional programming

  • Machine Learning & Big Data

  • Operating Systems

  • Security & Cryptography

Now with Free College Advice!

Below is an excerpt from the blog of Joel Spolsky, a software project management luminary:

Joel’s Seven Pieces of Free Advice for Computer Science College Students (worth what you paid for them)  :

  1. Learn how to write before graduating.

  2. Learn C before graduating.

  3. Learn microeconomics before graduating.

  4. Don’t blow off non-CS classes just because they’re boring.

  5. Take programming-intensive courses.

  6. Stop worrying about all the jobs going to India.

  7. Get a good summer internship.

Agreed; specifically, learning to write clearly is one of the most basic job and life skills. Joel became as influential as he did largely (if not primarily), due to his engaging writing.

0.3.2. Unlearning What You’ve Learned

Whenever possible, steal code.
— Tom Duff, Bell Labs 

In addition to the many things you’ve learned at University, there are several things that will need to be unlearned. In contrast to the go-it-alone atmosphere at school:

  • Start collaborating.

  • Use your books, Google, and Stack Overflow! Don’t just copy though, investigate and understand each snippet.

  • Read as much high-quality code as you can find; dig into a juicy open-source project.

  • As mentioned by Mr. Duff above, copy others (but check the licensing first).

Finally, stop trying to be so clever.  Instead, write the simplest, easiest to understand code you know how. Not only will others appreciate this, your future-self will too. Though sadly ignored or forgotten at times, defect prevention is a top goal and simplicity is an essential strategy to achieve it. We’ll discuss this at length in future chapters.

0.4. Choose Your Adventure…

You're traveling through another dimension, a dimension not only of sight and sound but of mind. A journey into a wondrous land whose boundaries are that of imagination.
That's the signpost up ahead—your next stop, the Twilight Zone.
— Rod Serling 

While reading the next few chapters, you might have a few questions in the back of your mind.

Is this what really happens?  In real projects?

It depends, what kind of “real project” are you on? The early chapters of this book describe a traditional, sequential software life cycle that may alternately appear very bureaucratic, just fine, or woefully inadequate depending on your current perspective. A number of other models follow which the book discusses at length, so don’t worry if the first doesn’t match your current situation. It’s useful to study several to find which (and which parts) apply best to the circumstances you’ll encounter in the future. Also, despite the sequential approach you’ll find each chapter chock full of modern practices, such as Continuous B.I.G. .  Simply start from the beginning for the “full monty .”

Likewise, large software projects are more often disasters than not sadly. sniff  Head directly to Project Challenges if you’ve a taste for the macabre  and a side-order of schadenfreude .

Where’s the Agile™?

As mentioned, the book starts with an unfashionable sequential approach and moves its way forward through history. Why? To understand a concept fully it pays to know the context (“old-fogey” cough stuff) in which it happened and the reasons why dominant practice has shifted—the most complete way to learn, also known as the “hard way .” Don’t worry, it won’t be that bad.

A classically-trained rock musician has the edge, all else being equal.
— Me (haha)

Further, in order to interleave multiple software engineering activities effectively in the future (as might be done under Agile/Scrum), it’s beneficial to study and practice each separately beforehand, as attempting them all at once would overwhelm the student. You may or may not use a sequential approach at a future job, but here it’s a great way (and excuse) to focus on one discipline at a time.

That said, if you’re still chomping at the bit to get to Agile because of a deadline or something, feel free to start with the Models & Methodologies chapter, continue through the Project Management chapters and then wrap around to the beginning as you have time.

One Way or the Highway?

Practices can (and should) be completely different depending on the circumstances. If a startup tries to use the same process as Google or Facebook, it'll be dead in the water. If SpaceX engineers write software the same way as SnapChat does, we will never see their rockets leaving their launch pads.
— kennethjiang on HN 

Correct—this book is a general introduction to software engineering that encompasses the field from “the enterprise” to web startups to mobile and embedded applications. Perhaps that’s too ambitious; time will tell. In short, while reading remember:

Hint:  Context Is Everything

There’s no single right way to develop software.

Indeed, wisdom in the field of software engineering is a bit mushy in the scientific sense. Whenever you think you’ve got the right way nailed down, those troublesome neurotic humans get in the way. Take what you read here as a starting point on the road to understanding, and remember to question and reflect on it at each opportunity.  If you’re in a hurry to get the parts that apply to your current project, kindly consult the sidebar and searchable index at left (or menu on your e-reader). Feel free to plow on or skip ahead—but first…

0.5. Purchasing This Book

Is this the real life?
Is this just fan-tip-sy   ♪
— Queen, "Bohemian Rhapsody" (w/apologies)

With introductory material is out of the way, now comes a word from our sponsor. As you may know, a book like this doesn’t write itself. It took years to learn and months without pay to write; not to mention the “mouths to feed” and numerous complaints from the wife enjoyed in the meantime, haha. ;-)

It’s also a work in progress (author underestimating the amount of effort required by an order of magnitude ). If you haven’t yet purchased it, please consider doing so to fund ongoing development of new chapters and fixes:

Buy All the Chapters!

Yes, this is a button. ;-)

  • Buy the full book  at Gumroad:

    • EPUB  and MOBI  versions—readable just about everywhere.

    • Remember, the book is still in progress and currently half price!  A purchase now (at the lower price) will entitle you to the full book when it is finished.

  • Buy at: Amazon Store   for Kindle, iOS, and Android, Mac, and Windows. (Has a few formatting limitations.)

Note:  Free Version

This is the free version of the book. Alternatively, by clicking a tagged link to Amazon , any purchase will “tip” the author a few percentage points for a few hours.

If you’ve made it this far, you’re on the right track. Thanks again. Now back to our regularly scheduled program, already in progress.

Your Quest Awaits!

Dragon's Lair: The fantasy adventure where you become a valiant knight, on a quest to rescue the fair princess from the clutches of an evil dragon. You control the actions of a daring adventurer, finding his way through the castle of a dark wizard, who has enchanted it with treacherous monsters and obstacles.
Lead on, adventurer. Your quest awaits!
— Dragon's Lair 


  • Computer Science and Software Engineering are separate yet complementary disciplines mildly related to each other. The study of one supports the other but both are necessary for success in typical software projects.

  • There’s no “silver bullet” to solve software engineering and project management, only challenging and fulfilling work ahead.

  • Read as much high-quality code as you can find; dig into a juicy open-source project.

  • “Learn how to write (a human language) before graduating.”

  • Write the simplest, easiest to understand code you know how, or suffer later.

  • Different projects require different approaches; your job as an engineer will be to select from the most appropriate.