Categories: Life

How to write down your top priorities

In the past year I’ve been trying to get my system for productivity and organization done. I have read and re-read Getting Things Done and things are slowly coming together. As I mention in a previous post, I’m using ZenDone for the list of next actions and the contexts that I can do those next actions, and I’ve been using Evernote for storing all sorts of notes and more details on the things I have to get done and for organizing projects.

[Update: 17 November 2018. I started to use Todoist in the past year to keep track of project to-dos. What I like is that it can show all TODO items scheduled for today, and it has another view showing all TODO items for the next seven days, so there’s a good agenda view.]

However, I’ve been missing something: a list of priorities for the day. This is different from a list of next actions and from calendar events; you may have to do some chores today but they aren’t a priority, you might have to go to three meetings but only one of those meetings is a priority.

The list of priorities for the day is an idea inspired by the book The One Thing. It proposes that we have to discover the one thing in life that we want to do and align everything around that. Ideally all of your priorities will be related to and aligned with the one thing that gives your life purpose and meaning.

Continue reading “How to write down your top priorities”

Categories: Life

Book List of 2014

 Books that I have read and started reading in 2014:

books

I always end up reading about work, whether it’s about the management or business or marketing details or about software development where I make my living.

The Sea The Sea and the Gibson novel are nostalgic throwbacks. I burned through as many science fiction and cyberpunk novels as possible almost a decade ago. The Sea The Sea is something I read when I was younger and I’m just curious to see what I saw in it since it’s a distant memory

Values At Play and Speculative Everything are a little more academic and formal but they’re going to have a huge impact on how designs of video games and the design of other objects happens (well they will have an impact as soon as we get these books into the hands of designers, creatives, product managers, software developers, interaction designers, etc. etc.)

Without the book Making It All Work and Getting Things Done (GTD) I would have been lost on many projects in life and in work. Following the GTD principles of checking, collecting, and finding the next action have helped keep me on track to finish everything. The hard part is getting enough control to gain perspective and plan for the future.

Systems Past: the only 8 software innovations we actually use

In the article, “Systems Past: The Only 8 Software Innovations We Actually Use”, David A. Dalrymple, writes that the major innovations in the tech industry were invented between 1955 and 1970. Since then, his position is that we have been incrementally improving on those concepts by lowering costs, improving performance and enhancing memory usage and optimizing various parts of the concepts.

I find that all the significant concepts in software systems were invented/discovered in the 15 years between 1955 and 1970. What have we been doing since then? Mostly making things faster, cheaper, more memory-consuming, smaller, cheaper, dramatically less efficient, more secure, and worryingly glitchy. And we’ve been rehashing the same ideas over and over again. Interactivity is now “event-driven programming”. Transactions are now “concurrency”. Internetworking is now “mesh networking”. Also, we have tabbed browsing now, because overlapping windows were a bad skeuomorphism from the start, and desktop notifications, because whatever is all the way in the corner of your screen is probably not very important. “Flexible view control” is relegated to the few and the proud who run something like xmonad or herbstluftwm on their custom-compiled GNU/Linux.

Can Bringing More Academic Ideas Give us More Room to Innovate?

Perhaps the solution to this incrementalism is to bring the ideas of computer science academia to the industry, especially the more esoteric ideas. For example, all the benefits of Haskell and type inference should be in mainstream languages. This is in fact starting to happen with Elm providing a better type system for front-end web development.

Though, on second thought, using better type systems and functional programming seem like more of an incremental improvement in terms of programming languages rather than a new innovation.

Can Using Formal Methods Give us More Space for Innovation?

It may be that when we reduce the costs of using formal methods, such as design by contract and model checking with Alloy, we will unlock more room for the abstract thinking that can lead to innovation. As it
is, in the daily life of a programmer (whether a web developer or or
embedded software developer), the main tasks are to piece components
together, find what functionality exists to be re-used and re-combined
and built upon, and to revise the code of others and to write many
many test cases to ensure the code is functioning as correctly as
possible.

Potentially there may be a reduction in innovation because we are not
giving developers more space to come up with revolutionary ideas and
not only to come up with those ideas, but to try them out and to
implement them in real-world systems.

Maybe we Just Need to use the Innovations we Already Have?

Maybe we do not need as much innovation, just the knowledge, skills
and time to implement the previous decades’ innovations. In the tech
industry, it is still possible to run across systems that have
absolutely no unit tests and have low quality assurance standards or
that do not use version control. How can we innovate when we still
have to deal with the security issues caused by the C programming
language? How can we innovate when we have created an industry where
the majority of work is in maintaining legacy systems?

How can a Software Developer get Started on Being Innovative?

A good first step toward innovative ideas is for software developers
to consider the bigger picture whenever they work on a project. By
this, I do not mean trying to bundle everything into a framework
(which we see happening with front-end JavaScript development and the
explosion of frameworks over the last decade with each stating they
contain brand new advances). Instead I mean keeping in mind that some
of the concepts used to solve everyday problems can be used to solve
harder problems. For instance, if the enterprise is building CRUD apps
or transforming data from one format to another, there must be some
other problem in there that needs solving. This problem could be a
deeper problem that cannot be solved easily by switching frameworks or
just adding a new library. It may require a new way of thinking or a
new algorithm or data structure to solve that the root problem.

Or maybe it is time to clamp down on the other parts of the
development process, and to discourage the poor management and poor
business practices that lead to failures in delivering projects and
lead to low overall quality in the development process. Possibly,
there is a knowledge/project allocation problem where we just need
developers to work on better projects where their talents can be
harnessed. The typical example of that would be letting the
junior-level developers worry about yet another CRUD app, while
allowing the senior developers and chief architects to work on higher
level skills. Maybe we need to go further and allow the bridge the gap
between academia and industry to be formed earlier.

It is interesting to think that the beginnings of the tech industry
spawned many great innovations and to consider that we are merely incrementing on those and re-implementing them.

Categories: Life

Book List of 2013

Books that I have read or started reading in 2013:

Generating a Culture of Code Documentation

Generating a Culture of Code Documentation

This is from a presentation given at the Write the Docs conference,

Cutter’s experience is that SMEs fall into three categories in roughly equal proportion: eager to help, willing to help (with guidance in the form of templates and direction), and curmudgeons.

…You as a writer have knowledge that engineers need to help them write docs effectively, and when you share that knowledge you help them write more docs. Hold doc office hours where you’re available to help them with docs. Because some text is better than no text.

Curmudgeons will say “but code documents itself!” Cutter calls “bull”; code only tells what it does, not its intent. [NB: Intent is worthless if the code’s action doesn’t match it.] Even if you know what you wrote immediately after you wrote it, six months later you’ll have moved on and that’s when the documentation becomes critical.

The Facebook experiment has failed. Let’s go back.

The Facebook experiment has failed. Let’s go back.

In the end, there is a lot to learn from this massive social experiment. Your friend circle and impulsive actions such as ‘likes’ cannot predict what you want to read. Indiscriminate sharing is a bad idea. A large social network isn’t the best way to find information.

We need to go back to smaller communities. Where people aren’t lost in the mediocre averages of large networks. That’s where ideas flourish.

Sounds like he wants the circles of Google+ (which makes it super easy to only share things with a select few people) or the ultra small social network of Path.

Categories: Life, Software Development

PLATO and the TUTOR programming language manual

I was reading a bit about PLATO, a computer system for computer-aided instruction, and it is astonishingly old. It was around in the 70s, the 80s, etc. The language originally used for creating lessons and tutorials was called TUTOR.

I’ve been extremely curious about the language since I first read about it on the weekend and I’m glad to say that I’ve found the manual.

The manual for the TUTOR programming language used on the PLATTO computer system can be found here. According to the description:

TUTOR is designed to transcend the difficulties of FORTRAN for a computer-based educational system utilizing graphical screen displays. The language consists of about seventy words or “commands”…

…authors are able to write parts of useful lessons after approximately one hour of introduction…

I bet there are a few gems in this manual. History is awesome.

What’s cool to me is that this manual is a predecessor to the interactive tutorials and quizzes that are available for online video courses, platforms like Khan Academy and Coursera and Moodle. While flashcards and quizzes are easy to create, interactive tutorials are difficult to create and there is no one dominant open-source platform for doing so. I think Khan Academy’s code is open source to some extent, but it mainly covers coding questions and math problems.

Categories: Life

Trying out Compass, a CSS Framework

[Update: 17 November 2018…it’s amazing to look back at this blog post from 2009 and see how much things have changed near the end of 2018. Right now we no longer use CSS frameworks; the last standing framework is Bootstrap, with CSS being written in whatever ways necessary to make React, Angular and other JavaScript SPA (Single Page Applications) look great. The SASS language for CSS now looks like pretty much like CSS and doesn’t rely on indentation by default with SCSS files. Some projects use SASS and Bootstrap supports it. What’s really changed is that I find it very useful to use Stylelint to lint CSS files.]

A week or so ago I decided to finally sit down and try out the Compass CSS framework. When I first looked at it, I was dismayed to find that it required Yet Another Language to learn, but then I quickly saw its advantages when I started using it.

The Compass CSS framework aims to be a real framework that does some heavy-lifting to let a web designer focus on CSS. It compiles a language called SASS into CSS and uses modules to allow integration with other “plain” grid-based CSS frameworks such as YUI GridsBlueprint, and 960 Grid System.

The SASS language is indentation-based and is similar to YAML. When Compass is run, it generates CSS files from the SASS files. This lets SASS provide all sorts of nifty things, such as inheritence, mixins, functions and variables. Inheritence and mixins are important because you can define a general border style, such as a left border that is solid thin and black, and then apply it to whatever CSS selectors you like. Then when you make a change to the border style, you only have to make the change once instead of finding/replacing the styles in all the selectors.

When trying to learn Compass, I decided to convert an old stylesheet to SASS. I wrote less than 100 lines of SASS to generate over 400 lines of CSS. On top of that, I used variables for different colours and added/subtracted to those colour values to generate new colours. Instead of finding/replacing and manually calculated, SASS took care of both of those things.

SASS functions let you calculate things based on the input that you give it. Just like functions in any other programming language. SASS mixins let you combine various styles under a CSS selector.

An example of the SASS syntax:

// example of a variable
!titleColor = #a3a

//example of a mixin/function
=minSize(!a)
  :font-size = (!a + 10) "px"

// inherited css selectors
a
  color: blue
  &:hover
    :color black
  &:visited
    :color purple

// more inheritence
body
  #header
    // color variable
    :background-color = !titleColor
    #blog-title
      // mixin/function call
      +minSize(22)
    #description
      +minSize(8)
      :font-family sans-serif
  #content
    +minSize(9)
    :background-color = !titleColor + #505
    #blog-post
      :font-family serif

And here is the CSS output that was generated by SASS:

a {
  color: blue; }
  a:hover {
    color: black; }
  a:visited {
    color: purple; }

body #header {
  background-color: #aa33aa; }
  body #header #blog-title {
    font-size: 32 px; }
  body #header #description {
    font-size: 18 px;
    font-family: sans-serif; }
body #content {
  font-size: 19 px;
  background-color: #ff33ff; }
  body #content #blog-post {
    font-family: serif; }

You can see how the selectors are nested and inherited. You can also see how the font-size of the various elements that used the minSize function were generated. The best part is the addition of two colours to create the colour for the body #content.

Basically, to summarize why you would want to use Compass:

  • SASS lets you use variables and functions to generate CSS
  • SASS lets you mix styles with different CSS selectors
  • Compass has plugins and modules to support the grid-base frameworks like Blueprint

This was a short post, mainly because as a programmer, the idea of variables/functions and a proper language for generating CSS is instantly appealing. So I’m hoping to create a module/plugin or plain template of my own for the MovableType blogging software and I’m attempting to convert templates and themes to use Compass to learn more about Compass and to improve my not-so-great web design skills.