A pleasant walk through computing

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

Accelerate Book Notes

2018-10-14 12:42

The contents have been moved to:

'Accelerate' Notes and Quotes

Getting Started With Software (and Business and Life) Skills

2018-10-09 12:56

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!

Contents

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.

Learning

Fufillment

Productivity

Business

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.

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

Methodology

  • 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

Testing

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

Platforms

  • Cloud Hosting: Azure, AWS
  • Docker

Miscellaneous

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

Shortest User Story Intro Ever

2018-09-13 07:59

Examples

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.

Example

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

Discussion

  • 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

Newer   Older