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

Why Am I Writing This?

I recently had a delightful meeting with a 29-year-old violinist who is making a career change into software. She's brim-full of ideas and excitement, has an entrepeneurial spirit, and is doing something very smart: asking other people what they think. She's going to get loads of advice, most of it well-meaning crap, which could very well include my information.

Her story spoke to me, because I'm a violinist, I got my first IT job when I was thirty, and I've been successfully self-employed. I've struggled with everything I'm suggesting.

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

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 she'll eventually find those. What I think, based on 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 as a collaborator
  4. 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

If I had to choose just three of the books/articles/etc below, what would they be?

Rapid Learning - 9 Articles Reviewed
I feel funny promoting my own work, but I think this blog post I wrote is a solid resource on how to learn.

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 [Book Summary ]
If this summary isn't clear enough, find another one. There are lots out there. I don't think you need to buy the book, but it's easy to find used. 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.

Randy Pausch, The Last Lecture: Achieving Your Childhood Dreams - YouTube
I know this is four things. But really, watch this. It's over an hour, and completely worth it. Dr Pausch was diagnosed with terminal pancreatic cancer. He delivers a heartfelt talk that would shame any "motivational speaker," because he's not motivated by fame or money since he, at the time, had only a few months to live.





Business Plans
In my 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.


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 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
  • 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 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.

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 Extenders (Less, Sass, CoffeeScript)
  • Dynamic web page languages and templates: WebForms, Razor forms,
  • Javascript language
  • Javascript frameworks: JQuery, Angular, Backbone
  • 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), difference editors (Beyond Compare, UltraCompare)
  • Languages: C#, VB.Net
  • HTTP
  • REST
  • WebAPI
  • SOAP
  • MVC (specifically models and controllers)
  • Pipelining: OWIN
  • Package Managers: NPM, NuGet
  • Unit Testing: MSTest, xUnit, NSubstitute
  • Dependency Injection/Inversion of Control: Ninject, Simple Injector
  • Authentication: OAuth, OpenID
  • Security: Cross-site injection, SQL Injection,
  • Performance
  • Other tools: Fiddler, PowerShell
  • Logging: NLog, Elastic Search,
  • Concepts: networking, routing, architecture (onion, service/data layers), view models

Web Server Back End

  • IDEs: Visual Studio, text editor(s), diff editors (Beyond Compare, UltraCompare)
  • 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
  • Pipelining: OWIN
  • Package Managers: NPM, NuGet
  • Unit Testing: MSTest, xUnit, NSubstitute
  • Dependency Injection/Inversion of Control: Ninject, Simple Injector
  • Authentication: OAuth, OpenID
  • Security: Cross-site injection, SQL Injection,
  • Performance
  • Logging: NLog, Elastic Search,
  • 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, TFVC, Subversion
  • IDEs: command line, SourceTree, Visual Studio extensions
  • Other tools: GitHub, BitBucket, GitLab


  • Development Approaches: Waterfall, Agile
  • Agile methodologies: Scrum, Kanban, Lean, eXtreme Programming
  • Project/Task Management: Kanban/Scrub board, TFS,
  • Issue Tracking: TFS, FogBugz, Jira, Bugzilla, Trac, GitHub, GitLab, BitBucket
  • Architecture Approaches: N-Tier, Domain-Driven Design, Onion
  • Continuous Integration/Release: Jenkins, TFS, TeamCity
  • Concepts: organization, teamwork, communication, creativity, problem-solving, estimating


  • Unit: Javascript, web, back-end, mocking, automated
  • Integration
  • Acceptance


  • Cloud Hosting: Azure, AWS
  • Docker


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

Shortest User Story Intro Ever


The template: As a [who/role], I want [what] so that [why]

The "why" is optional, but often useful.

As a Manager, I want to create employee schedules

As an Employee, I want to see everyone's schedules so I can arrange shift swaps

As an Analyst, I need to be able to view people's timesheet data in various ways so that I can better understand where work bottlenecks come from

Why They Work

  • They're written by stakeholders, typically users.
  • They quickly capture what users want, in their own words.
  • They aren't a feature specification. They are the beginning of a discussion.
  • If it's important enough for you (the user) to want, it's important enough for you to add a story

What If It's a Big Idea?

User stories often start as big ideas (epics). After discussion, they'll get split into smaller stories that can be better estimated and worked on.

Three Steps in a User Story

  1. Write the initial story (the value)
  2. Discuss the story and capture the discussion
  3. Determine acceptance criteria as needed

A user story is done when its acceptance criteria is met.


Value (or Title) As a Manager, I want to create employee schedules


  • What's involved in this?
  • How would it be done on paper?
  • How is it being done today?

A schedule includes employee name, id, date, from time, and to time.

[mm] I've found that the handwritten schedules end up being changed a lot due to employees swapping shifts, or being sick. All those changes make the schedule hard to read. So, it'd be great to easily reprint the schedule.

[hg] It sounds like how to print or display schedules should be a new story. What if we used kiosks instead of paper? Or maybe an app employees could view on their phones.

[ss] There needs to be control over who can change my schedules.

Acceptance Criteria
Initially, the scheduler system should:

  • Show an entire week
  • Add employee to a day and shift
  • Show employee total hours
  • Allow easy changing of who's working a shift
  • Allow easy swapping of employee shifts
  • Print a schedule

More Reading

A Simple, Effective Meeting Agenda System

I encountered this meeting agenda approach about fifteen years ago in a Microsoft certification study book. I've used it ever since, and it works great.


1.  Agenda Building
2.  Item 1
3.  Item 2, etc.
4.  Q&A
5.  Path Forward

The Simple System

  1. Send out the agenda a day in advance. Keep it brief and clear, so that attendees will understand what to expect.
  2. There are three items on every agenda. See below.
  3. Set a deadline and meet it. Defer items (except the last two!) if you have to, but don't run over time.
  4. Update the agenda document during the meeting. Immediately after the meeting, send the document with its notes and Path Forward to all participants.
  5. If you have Path Forward assignments, transfer them immediately to your task list.

Agenda Building

The first item is always Agenda Building. This is the chance for everyone to modify the agenda, either adding or removing items. You may be running the meeting, but it's not "yours." This helps everyone know they have a voice.


This is the last chance for people to make sure they understand what was discussed. If they don't ask, it's assumed they get it. The time to ask questions is in the meeting, not after the meeting. You'll be surprised how frequently someone will ask at this time, and be grateful the question got cleared up.

Path Forward

This is the most important item on the agenda. I hate meeting where, after it's over and everyone's walking back to their desks, people are asking, "So...what are we doing?"

The meeting's not done until you've captured who is doing what when.

Sample Finished Agenda Document

1.  Agenda Building
2.  Review plans for October Gala
	1.  Venue, food
3.  Results from Baker Makers promotion
	1.  Sophie stats
	2.  Candace P&L
4.  Are absences up? Concerns from staff.
5.  Q&A
6.  Path Forward
    -  Michael calling three venues for quotes by 7/31
    -  Misty finalizing catering by 8/12. Will email Naomi
    -  Andal reviewing BM promo stats, should be finished in three days
There's a general feeling that more people have been absent. Bad year for flu? Morale problems? Not sure how to approach this.


  • When the meeting is virtual or using a computer/projector, I like keeping the agenda on on the screen so people see notes being added.
  • I'll stress again: send out the agenda in advance. Ask if people have read it. If not, make them read it before you start the meeting. This will encourage them to read it in advance next time.

    Why is this important? Because it shows that you're prepared, and people like that in meetings. Don't let people come in asking "what are we talking about?"

Have great meetings!