Always be Learning

“At the end of a project, there’s two products. There’s the thing that you ship, but more importantly, there’s what you have learned.”

— Jonny Ives

I found this article about being a better web professional - Five Easy Ways to Be a Better Web Professional. I realized that I have several sites that I bookmarked on this topic. Most of these are specific to PHP but c'est la vie.

Always remember The Taxonomy of Terrible Programmers.

Becoming a dramatically better programmer.

The Case for Slow Programming. The Challenging Period - Web Design Weekly.

language agnostic - Why Use !boolean_variable Over boolean_variable == false

10 golden rules for becoming a better programmer

7 Good Developer Habits I Wish I'd Adopted Sooner

The software engineer's career path

50 Lies Programmers Believe

Code by Heart

Introduction to Open Source Licenses

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Signs that you're a good programmer and Am I really a developer or a good googler?

How to write a great error message

Why availability matters

I'm a Good Designer Checklist

CS for All

Becoming a dramatically better programmer

The 7 Habits of Highly Dysfunctional Developers

Learnable Programming

There is a great article entitled 'Why I'm The Best Programmer In The World' on Coding Horror.

7 Habits of Highly Successful Site Reliability Engineers

Taking the time to figure out how you provide value to a situation is a worth pursuit. Once you understand that, and come to grips with exactly why you are valuable, the rest is easy.
http://www.nczonline.net/blog/2013/08/06/understanding-how-you-provide-value/

Things I wish someone told me when I started programming.

  1. The number 0 is the number the same as the character 0. 0 does not equal '0'
  2. The characters 'a' ... 'z' are sequential (think ASCII) as are 'A' ... 'Z' and '0' ... '9' (think regular expressions - that is why we have to identify the ranges as az AZ 09)
  3. Objects receive messages
  4. Things end users care about but programmers don't
  5. Software engineering is programming over time.

Writing Good Code

Always write your own code.

Quality software is correct (provides functionality to satisfy requirements), exhibits robustness (can it handle unusual and unexpected demands?), and is accurate (describes how error-free the software is).

  • Use white space to give the code a chance to breathe.
  • Give each command its own line - clarity and readability.
  • Always use the shortest name possible which maintaining the meaning of what the variable holds.
  • One method to fill your code with comments to prepare the page first in English (avoiding all syntax). Then copy that text in as comments adding the code underneath.
  • Unit test - test the code itself. Test with a variety of data, including data outside the range of expected values.
  • Check for misspellings and invalid names.

Here are 8 ways to become a better coder.

JS Hint - write clean javascript.

The Importance of Writing Code That Humans Can Read

Watch Others Program Live

Ways We Work: a digital publication focused on telling stories and getting first-hand accounts of how people do the work they love

Software Architecture cheat sheet

How to Write Better Code: The 3 Levels of Code Consistency

Writing clearer error messages - a great article explaining why and how.

Don't forget your commit messages. Here are some tips on writing good commit message.

 

Notes on Usability

Here are my take-aways from Jakob Nielsen's Ten Usability Heuristics.

  • The system should always keep users informed about what is going on.
  • Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
  • Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
  • Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
  • Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focus on the user's task, list concrete steps to be carried out, and not be too large.

Thoughts on being a programmer

  • Don't be an asshole.
  • Simple code is hard to write.
  • Exquisitely simple code is exquisitely hard to write.
  • Just because it's easy to understand doesn't mean it was easy to write.
  • In fact, the easier it is to understand, the harder it probably was to write.
  • There are many ways to do something.
  • The first way you think of is highly unlikely to be the best way.
  • Anyway, there probably is no best way - just lots of ways that are differently good.
  • There's always plenty of room for improvement - in your code, in your abilities, in you.
  • If you think you're as good as you're ever going to be - you're probably right.
  • "One-line changes" aren't.
  • Learn to desire success more than you fear failure.
  • You're only old when you can no longer learn new tricks.
  • Always back up before tidying up.
  • RTFM.
  • Err vicariously.
  • Sometimes
    it's OK to be a bit of an asshole. But don't make a habit of it.

This page contains information I gathered and thought were very useful. See more notes on development.

Just to let you know, this page was last updated Monday, Mar 18 24