Every time I’m in a room full of developers I’m amazed at the collective knowledge of the variety of different programming languages, practices, frameworks and technologies. When I attend meetups, conferences and/or hackdays I often discover something I’ve never heard of before. 

It’s very stimulating, but it used to stress me out. At the end of an event I would often think to myself:

“How can I not have learnt to use x, y and z? When am I going to do this?”

The result would be a few forced hours trying to catch up with everyone else. 

Eventually, I realised there’s a bottomless toolbox of tools I could be learning. Whether we like it or not, we’re not going to be able to learn everything. It’s just not practical to worry about it. 

Employers seem to forget this. This is an excerpt from the first job ad I clicked at random from careers.stackoverflow.com: 

“On one side, you deeply empathize with users, understanding the visual and user experience design process and contributing deep thinking to make experiences more engaging and magical. On the other side, you know data and back-end technologies (Advanced Javascript, Ruby, MongoDB, PostgreSQL/MySQL), code frameworks (Rails 3+, jQuery, Sencha Touch), and other tools, technologies and patterns (MVC, node.js, Omnigraffle, Mobile/Tablet environments, Cloud Infrastructure/AWS) inside and out, providing a solid, scalable platform that delivers an immaculate experience.”

After listing a mixture of more than a dozen tools and technologies the applicant is asked to know these “inside and out”. 

In my view, a developer’s most important skill is his or her ability to learn. You shouldn’t get refused a job because you haven’t upped your knowledge of CSS to cover CSS3 (true story). 

This isn’t to say I don’t bother trying anything new. I’m learning on the job almost every day. It’s a requirement of being an freelance developer. I need to take care of almost every aspect of development.

As much as this serves me well, I still need to keep up with developments. I’ve decided to resolve the dilemma by giving myself access to the tool rather than owning it. 

That is to say, learn what the tool is for, familiarise yourself with its advantages and disadvantages. To help achieve this, find a concrete example of where it’s being used and how it benefits its employer. In some cases, it may be useful to give it a shot and see what it’s like, but not in every instance. Without spending hours and hours this little preparation could go a long way to ensuring you’ve got the right tool for the job.

Recently, a friend of mine asked if I had some photos/resources left from our old uni project ‘CTRL’ to put in his portfolio. Incredibly, I found some shots of our over-ambitious attempts to alter a keyboard. 

Here’s a little extract from one of the reports:

“We took on the task of building a system to teach keyboard short-cuts. Keyboard short-cuts are often ignored and even users with high computer literacy usually know only a handful of such commands. To begin with we only had our suspicions on the use of short-cuts, we also found that when we have tried to teach others in the past by simply explaining to them they rarely get remembered. As a result, we felt it was necessary to show, rather than tell…”

As well as the hacked apart keyboard, we wrote a desktop application that suggested short-cuts based on your ability.

It was only a short project, so we didn’t have much time to test it in the open. However, we received a good response to the idea when we conducted our questionnaires and interviews - especially when we talked to OAPs. We learned you’d much rather use a keyboard than a mouse if you’ve got arthritis.

Developers and designers should take the time to build keyboard controls into applications. It can make a world of difference to some people. I know I’m not the only one that believes this. After all, my team mate won an award for her work on the project at the ‘BCS Women Lovelace Colloquium’.

Anyway, I’ll leave you with a list of handy keyboard (Linux / Windows) short-cuts:

• Windows + D (or Super + D): Minimises all windows and shows the desktop
• Alt + Tab: Switch between windows
• Tab: Cycle through buttons / input boxes / etc
• Shift + Tab: (same as above, but the other way)
• Alt + F4: Closes the current window
• F2: Rename selected file (have to say I’ve not really used this)
• Ctrl + A: Select all
• Ctrl + Alt + (Left or Right Arrow): Switch Work Space (Ubuntu only)

The list goes on and on…

I probably shouldn’t have to mention my best friends ctrl + c, x, y, and z.

If you are not familiar with the last 5, you should probably stop what you are doing and learn them right now. If your life involves computers in any way, you’ll probably save thousands of hours in doing so. 

On Wednesday, I taught the final session of a Ruby on Rails class at Stow College. I’m glad to say there are more courses in the works for Glasgow and Edinburgh next year. All in all I’ve found it a pretty satisfying experience. I’m very happy with how it went but now I’m reflecting on how it could be improved.

Most software / IT training courses intended for those of us in the industry are run back to back over a couple of days. In a break from this norm the Ruby on Rails class was split over 6 weekly sessions of 2 hours each. Before the beginning of the course I felt this was definitely the better option. 

This isn’t an insignificant decision as it costs all the delegates more in terms of travel and time. When compared to a full weekend back to back it also means slightly fewer hours of instruction.

After doing the course I’m still convinced that it’s better for the students if the course is spread out over a few weeks.

Why? 

Stackoverflow

Unless you really are that hardcore I don’t think you’re going to take everything in. Even if you really feel hardcore, consider that your instructor has to intensively teach you for those hours. At the end of the 2 hour blocks I was ready to stop. Although I wasn’t completely exhausted, I felt that if I spent any longer performance would start to drop.

Homework 

I never liked homework. I didn’t ask anyone to do any but I certainly encourage people to experiment and exercise what they’ve learnt then bring their experiences to the next session.

On intensive courses such as these, instructors are going to assume a certain level of knowledge. I know I did. Perhaps a bit too much, and perhaps I didn’t do enough to make sure people were 100% with the foundation concepts. 

There isn’t a chance to do this if your sessions are back to back. Discovering something you didn’t know the first hour into a two day course would a magnificent pain in the bum.

Overall, I think the format caters quite a lot to the experimenters out there. Those who need time out of the boundaries and guidelines to really learn. A bit of self-learning and experimentation interspersed with two hour guided sessions will certainly put your self-learning on steroids. 

The best time to remember something is when you’re about to forget it.

Apparently, the timing of reminding or repeating something is significant in learning. Although I haven’t calculated the optimum for learning a new framework blitzing it in one go probably fails the test.

Alternatives

Still, there are plenty more ways to format a course. I’m not saying this is the one true answer. I’m just trying to pick out what worked and what didn’t. As a result, I’ve given some thought to alternatives. Any ideas welcome!

3 x 4

Dividing the 12 hours into 4 hour blocks was suggested by a delegate on the previous course. Provided coffee, good preparation and some effort I reckon you could keep the pace up while leaving at least some digesting time in-between sessions. However, it’s probably not going to work on a school night. A good alternative but it probably means restricting the course to precious weekend time. 

4 x 3

4 sessions of 3 hours. This could probably be the best of both worlds. Still, I don’t know how I would feel tackling this after a busy day.

Others?

Have you been on a software related course that had a format that really worked?

Passion is something we’ve all heard about in the context of launching ventures. 

I’ve been reading Eric Ries’ ‘Lean Startup’. Even though it’s all about boiling the startup process into measurable tests and actions, passion and vision are still important.

It’s not Ries who’s got me thinking, but Tim Ferris. In Ferris’ blog and book, ‘The Four Hour Workweek’ he encourages us to create a ‘muse’ - a business that we can automate and separate ourselves from. In other words, keeping control but removing it as far from our lives as possible.

With a strong emphasis on passion, this philosophy really feels at odds with the Go for it! Change the world! approach. It’s not the first time I’ve come across this view though.

However, don’t let me give you the wrong impression, ‘The 4 Hour Workweek’ is filled with passion. Just not when it comes to starting ventures. Rather, ‘The 4 Hour Workweek’ is passionate about all the things you get to do when you’ve given up your day job and you have an automated business supporting you. 

For many people, work is too much an important part of their lives to be relegated to 4 hours a week. For others, this approach is very relevant. I think the real question is: Why do you want to start your own venture?

Is it so that you’re in charge of a great company affecting peoples lives?

 - OR -

Is it because you get to hang with cool cats and travel the world visiting the company offices on your boat?

If the answer is the latter, consider this: you may not need to be the CEO of a public listed company to achieve this. Even better, you can skip out on the offices and spend more time on the beach.

Passion is important. But so is knowing where it is and why it’s there. 

Well, that’s my take. What about you?

Tomorrow I’ll be giving a talk at an informal SIE event for students. For those that don’t know, the SIE is a Scottish organisation setup to encourage and support students entrepreneurial ventures and abilities.

One of the SIE interns got in touch and asked if I could speak for 10 minutes on the very wide topic of ‘technology’. More specifically, if I could talk about emerging trends, apps I like, and a bit about what I’m doing. In the same session there will be a mini-ideas competition to judge.  

I was happy to oblige and to spice things up I agreed to spend time with the winning team to hack-up a prototype of their idea. This will be on the condition that they go out and validate their idea with some real customers. 

Deciding the content of the talk wasn’t as easy as I initially thought. How can I be helpful in 10 minutes? What really are the big trends in the world of tech? The latter is a question countless blogs, magazines, and arm-chair gadgeteers dedicate their time to. I could tap in to these sources for inspiration, however I get the impression that anything that isn’t sexy or visible is left undiscussed.

I’ll have to mull it over. One thing that will certainly get a mention is ‘the cloud’. Although it may have entered the public conscience, I don’t think it’s significance is really understood. Rather like ‘2.0’ is now slapped onto all things cool and alternative, I think we can expect to see equally cringe-worthy statements/slogans using ‘the cloud’.

I think I could really help those with ideas which are hinged on technology but have no idea where to start. More than once I’ve encountered a few people like this and it seems their expectations are non-existent or slightly deranged. 

Rather annoyingly, the phonegap getting started guide hasn’t been updated. Since version 1.0 a few things have changed.

You’ve got to add this line 

super.init();

to the end of your DroidGap class ‘onCreate’ method. *

*Scrap that sorry - it turns out you don’t need it after all.

You’ve also got to add a folder called ‘xml’ under ‘res’, then under the ‘res/xml’ directory you add this xml in a file called ‘plugins.xml’.

In two weeks I will be taking an ‘Introduction to Rails’ at Stow College in Glasgow. I thought I’d take a moment to encourage more applications and answer some questions I’ve already had from applicants.

First of all let’s get the basics out the way. Most of these can be found on the course page on Stow’s website.

Basics: When & Where?

On Stow’s main campus. It’s a short walk from Cowcaddens subway station. Starting the 24th October the course will run weekly on a Monday at 6.30PM. There’ll be 6 sessions, each session lasting 2 hours. 

Basics: How much?

£300. However you can get £200 towards this cost with an ILA Scotland grant.

Is it for me?

OK, now for some of the other questions.

The course is from scratch. I assume no prior knowledge of Ruby and/or the Rails framework. However, I do assume you’ve done some kind of web-development. Therefore you should have database fundamentals and be up-to-speed on an object oriented programming language. 

You may be pretty new to the web development game which is OK or you may be a maestro adding another tool to his box. Either way, you may wonder why bother? Off the top of my head: speeded up development time, lowered barrier to entry and transferable practices. Don’t take my word for it, read about it from Tom Mornini, CTO of Engine Yard (one of the biggest rails cloud platforms).

Why not try it?

Sometimes you just have to get a feel for things before you know for sure. Why not try ruby? There’s a great in-browser 15-min tutorial tryruby.org. Alternatively, you can try it on repl.it.

How will it be taught?

Time to think

Unlike most offline courses, this course is split over 6 sessions. If you’ve had a look at the alternatives they usually cram roughly the same amount of teaching into a weekend. I hope you agree when I say I think this might be a preferable format. There’s a lot to learn. By giving yourself a week to digest, try some things out and come back after a week is the way to go.

If you do come back with questions there’ll be some time to chat these over in class. If you’re way ahead (or feel you’re behind) others there’ll probably be a chance for me to chat with you one on one too. The class will be relatively small (it’s capped at 15) so there should be time for extras.

Practical

In terms of format, I’m aiming to make the course very practical. In particular, I’m aiming for 50-50 split of teaching/discussion and hands-on development. Also, I would like the work of one week to build on the previous. Therefore, at the end of the 6 weeks you should have something resembling a simple web-application.

Can I use my own laptop?

Yes you may. However, I must ask that you come with a working ruby compiler installed. You’ll also need to be connected to the internet. Although I cannot say for certain, wireless access should be available in the College. 

What would you like out of the course? 

When we start the course I’m going to ask attendees to talk about what they’d like to have learned by the end of it. What will you be able to do? Where will you be able to go from there? I think articulating this I’ll be able to deliver a better course and you’ll get better satisfaction out of it since you’ve defined exactly what you’re after! 

What’s your experience learning rails/web-dev.? 

This question is for those who have learnt rails or any other web-dev. framework for that matter. It would be great to get some opinion on the following:

• What aspects were the hardest to learn as a novice?
• Was there anything you wish you knew starting out?
• What helped you click and understand something?
• What mis-understandings or mistakes do rails or web-dev. novices often make?
• What would you teach first?

Anyway, I’m looking forward to it! If you’ve got questions about the course just get in touch!