A pleasant walk through computing

Comment for me? Send an email. I might even update the post!

Getting Started With Software (and Business and Life) Skills - 2023

Contents

Why Am I Writing This?

I wrote my first version of this article in 2018, inspired by a young violinist-turned-developer. This time I'm thinking about some colleagues who are already in the field and wondering what might help them in their careers.

What interested me was how to answer a question: What do I think a junior software engineer needs to know?

Most of what I wrote in 2018 holds today, so there's some copy/paste going on below, but I've asked, "What matters to me now?"

The answer has almost nothing to do with programming. Oh, sure, I could list a whole bunch of programming resources that even I haven't read. But curious developers eventually find those. What I think, based on over twenty-five years of experience in the industry (plus fifteen years in retail, food service, and other jobs before that), is that a successful, fulfilled person needs to:

  1. Learn how to learn
  2. Know what it means to know something
  3. Communicate well in good and bad situations
  4. Find a job that aligns with one's purpose and values
  5. Savor life

Are there skills specific to being a programmer? Sure. See Appendix A. But I think they don't matter without the basic human stuff. You're not going to find (much) fluff below, because one of my mottos is "show me the science."

So . . . here we go!

Principles Du Jour

  1. Develop skills. Knowledge will come.
  2. Little habits add up.

The Big Hitters

Last time I chose just three books/articles. I can't do that this time. These are my current top recommendations.

Good Habits, Bad Habits

There are other good books on habit-forming out there, but Dr Wood is a premier researcher on the subject. When about 40% of your life is habits, it's a good idea to turn them to your benefit.

Leadership is Language

Combining current science with compelling, practical stories, submarine captain David Marquette explains how and why he transformed himself from a command-and-coerce leadership style to collaborate-and-improve. It was literally a matter of life or death. I recommend this book all the time.

Crucial Conversations

I think the essence of this book is, "Be 100% honest, 100% respectful, and keep it safe." I've always been good at the first one . . . not so good at the other two. This book helped me improve my relationships.

Drive: The Surprising Truth About What Motivates Us

Daniel Pink delivers one of the most important books I've read on motivation.

Getting Things Done

I've used, adapted, and revisited GTD for over ten years. It's helped me tremendously. In my view, Allen's crucial messages are:

  1. Get everything you want to do out of your head and into a system you trust.
  2. The purpose of a personal productivity system is to reduce stress, not get more done.

Career Lab

This is a departure from the above books. Are you trying to figure out what your career should be like? Or considering transitioning? Bill is a consultant, and if you can afford to you should pay him for his expertise and experience. For those who can't, he's provided a real treasure: his entire methodology is on his web site. I took a month to work through all his exercises and they really focused me on my values. Hard work, worth it.

Learning

Fufillment

Productivity

Business

Business Plans
In my 2018 meeting, I was asked about business plans. I have limited experience writing a business plan, and I knew there'd be plenty of resources available online, such as those listed.

Here's my opinion: unless you're seeking investors or a loan, the point of working on a business plan is to get you thinking, and to prepare for conversations with other professionals. This quote sums that up nicely.

"In preparing for battle I have always found that plans are useless, but planning is indispensable." --Dwight D. Eisenhower

Communication and Presentation

Despite not listing any resources below, communication and presentation might be the most important area any person can work on.

  • Interpersonal (Toastmasters, acting, practice presentations and record them).
  • Simple courtesies: thank-you notes, formalities, emails.
  • Follow through. Under-promise, over-deliver.

Programming-Specific

Developing a software engineer curriculum is hard, because there are about twenty subject areas. Start with what interests you, the rest will follow. See Appendix B for an overwhelming list of what it can take to write a single, professional web application.

  • Learn about the fundamentals of programming and what's physically happening in the computer. A lower-level language like C++ helps with this, but don't learn the language, just the concepts. A partial list: what are . . .
    • Memory addresses
    • Arrays
    • Collections (such as linked lists and dictionaries)
    • Sorting
    • Loops
    • Iterating and Enumerating
    • Objects
  • Manifesto for Agile Software Development
  • Principles Behind the Agile Manifesto
  • Fundamentals of eXtreme Programming/Scrum/Kanban/Lean. Try one (I like Kanban).
  • Accelerate: The Science of Lean Software and DevOps <= One of the most important books on development practices today
  • The Art of Agile Development <= I trust James Shore's approach and understanding. It's not faux-Agile.
  • Podcast: Developer Tea <= Ten minute programs about improvement. I love this show.
  • Find the [your-language/platform-here] version of Morning Dew - Daily links for Windows and .NET developers.
  • Automate repetitive tasks
  • Systematize administrative routines (tasks, calendar) (plain text is great). That is, make it easy to practice GTD or whatever method you choose.
  • Tools are an aid, not an end. Learn your tools, but don't become a tool junkie.
  • Be ruthless about maintainability (and maintenance)

Appendix A - Skills (I Think) Software Developers Need to Cultivate

Sorry, I know I'm all about evidence, but I haven't researched this. Here is my opinion on skills/traits specific to software development.

  • Puzzle/problem solving. Programmers have to be able to solve problems. In my opinion, the very best are interested in how to solve problems multiple ways, and never think they have the only right answer.
  • Tenacity. Programmers are faced with tasks that take hours, days, or months to accomplish. They face problems that often don't have obvious or simple answers. They have to keep after it. And they're sitting in a chair, which is completely unhealthy.
  • Abstract thinking. This is a fact, because software is an abstraction. Programming is one of the few fields where what you see is not what you get. Developers stare at words that are instructions later interpreted to produce something someone sees. It's not natural or easy. Imagine your job was to describe, in braille, how to write an English document that explained all the steps to painting Van Gogh's Starry Night, and if the painting doesn't look right the braille book doesn't open.
  • Communicating complexity simply. On a scale of 1 to 10, most programmers reach about a 2 on this. A program is like a night at the theater (or movie, or symphony). You, the audience (manager, user) have no idea what it took to create. It looks simple, it must have been. Developers, especially seniors, must be able to explain how something seemingly simple will work, and why it will take a year to do it.
  • Understand everyone else's job. Scale of 1 to 10: most programmers are a 3 (but think they're a 7). This really depends on what area of software you're working on, but it's rare for programmers to work on software they use. A consulting shop will work for all kinds of clients. In addition to the gobs of information about their own jobs, programmers often need to understand essentials of diverse fields. I, for example, have needed to rapidly learn about: accounting, manufacturing, aircraft maintenance, and radio-nucleotide decay, to name a few.
  • Research. Programmers need to be able to figure out how to query the internet for information, then they have to evaluate the dozen different answers and determine which, if any, fit the issue at hand. I spend as much time researching as I do programming.

Appendix B - Everything You Might Need to Know To Create an Enterprise-Level Web Application

Don't worry, I promise you'll get there. And most of the time, you'll work with other people who know the stuff you don't.

These lists are heavily weighted toward the Microsoft development stack, because that's what I know.

User Interface

  • IDEs: Visual Studio, Visual Studio Code, text editor(s),
  • Design Prototyping: Balsamiq
  • Design Images: Photoshop/GIMP/Paint.Net, Illustrator/Inkscape
  • Image Formats: JPG, PNG, GIF, SVG
  • HTML
  • CSS
  • CSS preprocessors (Less, Sass)
  • Dynamic web page languages and templates: WebForms, Razor forms, Blazor
  • Javascript language
  • Javascript server-side development: Node
  • Javascript frameworks: Angular, React, JQuery
  • Javascript style checking: ESLint
  • Javascript Unit Testing: Jasmine, Karma, Angular-mocks
  • Package Managers: NPM
  • Integration Testing: Selenium
  • Authentication: OAuth, OpenID
  • Security: CORS, Cross-site injection
  • Performance
  • Other tools: Chrome F12, Fiddler
  • Concepts: page layout, colors, user experience, accessibility (handicapped), minification, HTTP protocol, MVVM, MVC (specifically views), REST, mocking, dependency injection

Web Service

  • IDEs: Visual Studio, text editor(s)
  • Diff and Merge: KDiff3, WinMerge, Beyond Compare
  • Languages: C#, VB.Net
  • HTTP
  • REST
  • WebAPI (models and controllers)
  • SOAP
  • Package Managers: NPM, NuGet
  • Unit Testing: MSTest, xUnit, NSubstitute
  • Dependency Injection/Inversion of Control: .NET Core dependency framework
  • Authentication: OAuth, OpenID
  • Security: Cross-site injection, SQL Injection,
  • Performance
  • Other tools: Fiddler, PowerShell
  • Logging: NLog, Elastic Search, Application Insights
  • Architecture: Onion, distributed, (micro)service-oriented
  • Concepts: networking, routing, view models

Web Server Back End

  • IDEs: Visual Studio, text editor(s)
  • Diff and Merge: KDiff3, WinMerge, Beyond Compare
  • Languages: C#, VB.NET
  • HTTP
  • MVC (specifically models and controllers)
  • ORM: Entity Framework, NHibernate, Active Record
  • Architecture (layers, onion,...)
  • Web Servers: IIS, Apache, Node.js
  • Javascript server-side development: Node
  • Package Managers: NPM, NuGet
  • Unit Testing: MSTest, xUnit, NSubstitute
  • Dependency Injection/Inversion of Control: .NET Core dependency framework
  • Authentication: OAuth, OpenID
  • Security: Cross-site injection, SQL Injection,
  • Performance
  • Logging: NLog, Elastic Search, Application Insights
  • Architecture: Onion, distributed, (micro)service-oriented
  • Concepts: networking, routing, view models
  • Other tools: PowerShell
  • Concepts: networking, routing, data modeling, business entity modeling, business rules, test-driven development, REST, mocking, dependency injection

Data Persistence

  • IDEs: SQL Server Management Studio, LINQPad, text editor(s)
  • Languages: T-SQL, LINQ,
  • Databases: SQL (Microsoft, Oracle), No-SQL (MongoDB, Redis)
  • ORM: Entity Framework, NHibernate, Active Record
  • Authentication (network)
  • Security
  • Performance
  • Other tools: Redgate, PowerShell
  • Concepts: database design, data modeling, relational design

Version Control

  • Source control systems: Git
  • IDEs: command line, Visual Studio extensions, VS Code extensions, Git Kraken
  • Other tools: GitHub, BitBucket, GitLab

Methodology

  • Development Approaches: Agile, Waterfall, Lean
  • Agile methodologies: Scrum, Kanban, eXtreme Programming
  • Project/Task Management: Kanban/Scrub board, Azure DevOps
  • Issue Tracking: Azure DevOps, GitHub, GitLab, BitBucket
  • Architecture Approaches: N-Tier, Domain-Driven Design, Onion, Service-Oriented, Microservice, Distributed
  • Messaging: service bugs, message queues
  • Continuous Integration/Release: Azure DevOps Pipelines (YAML-based), Infrastructure-As-Code
  • Concepts: organization, teamwork, communication, creativity, problem-solving, estimating

Testing

  • Unit: Javascript, web, back-end, mocking, automated
  • Integration
  • Acceptance
  • Exploratory
  • My current favorite unit testing stack:
    • xUnit
    • NSubstitute
    • FluentAssertions

Platforms

  • Cloud Hosting: Azure, Amazon Web Services, Google Cloud
  • Docker

Miscellaneous

  • Microsoft Office (Word, Excel, PowerPoint)
  • Email
  • Stack Overflow web site for researching problems

Why I Don't Use Dark Mode - Science!

A colleague asked my thoughts about dark vs light modes, so here's the quick answer I gave him. It doesn't have my usual list of references, you can do your own research this time!

Generally speaking, our eyes work less when reading dark text on a light background. When trying to read light next on a dark background, our pupils dilate, resulting in the text being fuzzier and both our eyes and brain working harder to read.

There are exceptions you might see, such as older footage of air traffic control at night where the text is orange. But that's only text, not our graphics-heavy displays, and those orange (or green) choices were based on some science.

Reducing screen brightness and color range may--probably does?--help reduce eyestrain in a dark environment. I haven't checked the research on that.

Personally, I generally configure my computer/apps this way:

  • Use a dark, non-distracting wallpaper (often a single color)
  • If the app allows, use darker backgrounds for "background" areas.
  • Use dark text on light backgrounds.

I use f.lux to manage my screen color/brightness. I find it better than Windows's built-in utility. I've adjusted it to what's comfortable for both day and night (do enable the extended color range). If I ever have to edit images at night, I need to disable f.lux if I care about color accuracy.

One other concern I have--my opinion, not researched--is that our brains are evolved to be more afraid in dark environments and light text on a dark background might be triggering my sympathetic nervous system (fight/flight). I don't want any more stress in my life than needed.

Dark modes look cool, but I abandoned them quite a while ago based on the evidence as I understand it.

I take it back: here's one reference.

Dark mode isn't as good for your eyes as you believe | WIRED UK

The Mythical Man-Month: A Short Review of the Essential Essays

A book club I belong to agreed to read Frederick P. Brooks's seminal essay collection The Mythical Man-Month. We somewhat abandoned the book, finding a lot of it hard to relate to because we don't write operating systems for specific hardware in a time-sharing environment. Plus there's no audio version, which is how some of the members like to read. I promised the group I'd read some specific essays because I wanted to, and report back.

I've made good on that promise. I think the following are worth reading for a few reasons, which I touch on below. Something not clear initially is when the essays were written. I think that's important for the context, so include what the dates seem to be.

The Tar Pit (1975)
While not essential, this short essay nicely discusses what makes software hard and enjoyable. I think most of what Brooks says holds true today.

The Mythical Man-Month (1975)
For the title essay, the thesis has held up; adding developers (to a late project) doesn't reduce time-to-completion. Communication is a core challenge of software shops. When new developers are added, there's significant ramp-up time for them, plus other employees' training time devoted to them--taking time away from their own days.

No Silver Bullet (1986)
This is Brooks's other most famous essay, written just as microcomputers are coming on the scene. In it he proposes software development won't see magnitudes of performance improvement from any single tool or process. He also breaks down why that is, and comparing software development to hardware development makes an observation I hadn't considered: it's hardware development that's the outlier. The incredible advances in power coupled with reduced cost hadn't--and haven't--happened in any other industry.

Reading this essay is watching history unfold. Brooks is excited about new approaches--such as objective-oriented programming!

'No Silver Bullet' Refired (1995)
Here, Brooks examines his own essay nine years later. What a difference those years make! And yet, he argues that there is still no single silver bullet despite many advances. He discusses the various critiques of his essay, acknowledges where they're valid, points out where they're not. I enjoyed that he quotes Capers Jones on the subject of productivity.

"NSB," like most writings at the time, was focused on productivity, the software output per unit of input. Jones says, "No. Focus on quality, and productivity will follow."

I completely agree.

The Mythical Man-Month after 20 Years (1995)
This might be my favorite essay. Brooks discusses his entire book, where he was right, and where he was wrong. With gracious humility, he says, "I dismissed Parnas's concept [of information hiding] as a 'recipe for disaster' in Chapter 7. Parnas was right, and I was wrong."

He reveals discussions with the great James McCarthy of Microsoft who pioneered incremental and iterative processes we take for granted (even when business still don't do them!). But mostly, this essay is a snapshot of the industry approaching a turning point of both powerful personal computers and, in a few years, the codification of Agile values and principles. He names bunches of software, a lot I recognized, and most of which is no longer in use.

1995 was only a year after I entered the computing industry. I wish I'd found this book then, though I wouldn't have understood it. So much of what we talk and read about seems new, but Brooks and his colleagues were struggling with--and solving--these problems already.

We owe these masters a debt, and maybe that's why I'm glad I didn't give up on reading more of the book. I feel I've, in a small way, said "thank you" to those who came before me and made my career possible.

One final item. While the essay Why Did the Tower of Babel Fail didn't make my list, I wrote a fuller article about it on my blog. It disputes Brooks's Tower metaphor, and won't be to everyone's taste, but here it is for you to decide for yourself.

Meditation On The Mythical Man-Month: Who Failed On The Tower Of Babel Project?