Thanks to all the people that came along to the BSC London presentation I gave last Wednesday. Despite the threat of weather potentially cancelling our, previously snow-canned, presentation, it went ahead much to my delight. I hope that you all got something out of it. I’ve uploaded the slides here if you’d like it.
Page 29 of 53
As I gather more experience (i.e. get older) I’ve discovered every model has a breaking point. What does that mean and why should you care? Accepting that models break is the first step to understanding and identifying their limitations. More importantly, because models have a breaking point, you should be actively discovering other models that help you better communicate and grasp new concepts.
Sounds easy right? Unfortunately my experience in life proves the opposite with most people wanting to only hold a single “valid” model that manages to explain and justify everything. I see this as a consequence of western education guided by Socratic thought and a Platonic ideal but that is a post for another time. In real life, this desire to hold onto “one valid model” translates to arguments over the merits of a particular model and often the basis for justifying a position. Note that I have no problems arguing for the sake of testing and discovering the boundaries of a particular model.
What do you do about it?
Accept that models are simplifications of sometimes complicated, sometimes complex systems. Be open to exploring the boundaries of a particular model, uncovering where one model excels at explaining certain characteristics of a system. Seek out and invent new models that provide a different point of view, or that emphasise and highlight different aspects for that system.
One of the biggest differentiators between the users who prefer IntelliJ over Eclipse is often their dedication to learning keyboard shortcuts. The user-conscious designers of IntelliJ make as much as they can consistent, something much more difficult for Eclipse, who is dependent on a community for plugin development without any process for reviewing how well they all fit together.
On my very first ThoughtWorks project, I remember my pair commenting about how I should learn all the keyboard shortcuts for IntelliJ. Learning keyboard shortcuts is less about churning out great amounts of code, and much more about avoiding interrupting your flow. Simple actions, such as reaching for mouse have potential to break your flow. Jetbrains make it easy to learn the keyboard shortcuts, even providing a printable cheat sheet so you can put them around your workspace as you learn them.
Having said all of this, here are some of the keyboard shortcuts I find myself using all the time for iPhone development:
- Switch to Header/Source File– ALT + CMD + UpArrow
- Open quickly – Shift + CMD + D. This is as close to Jump to Class/Method/Symbol that I could find so far. I haven’t worked out how to search using regular expressions yet.
- Go back/forward – ALT + CMD + LeftArrow/RightArrow. Moves back between files that you opened. Useful for cycling through a call stack
- Go(Run) – CMD + Enter. I’m currently using this to quickly see results as a spike my way through learning about Objective C and the APIs
- Open Console – SHIFT + CMD + R. Useful when debugging using log statements and looking at what’s going on.
I’ve also found application-wide standard keyboard shortcuts really helpful as well
- Cycle through different applications (XCode, Interface Builder) – CMD + TAB
- Cycle through different windows in the same application – CMD + ` or CMD + ~. These are all really useful because Apple applications have a tendency to open many many windows, not really ideal for keyboard use.
- Open help – SHIFT + CMD + ?. This is really useful when no keyboard shortcut is mapped, or you want to access a menu and can’t remember what it was. Once you have the Help dialogue open, start typing the name of the menu item. I’ve used this quite a lot to access the Refactor menu item which pops open another window.
Of course there are many more keyboard shortcuts. These are simply the ones that I’ve found I’m getting the most productivity. I wouldn’t say all of development can driven through the keyboard alone, but it’s a pretty good start for now. What are your favourite ones?
I’m a huge believer in accepting multiple models as different ways of looking at the same set of data. It’s just simply different glasses to see different things through. One of the glasses I’ve been putting on more consciously is that of David Kolb and his model on experience learning. Read more about it here.
It follows a simple cycle: Experiencing -> Reflecting -> Generalising -> Applying -> (Back to Beginning)
Here’s how I go about applying it. I follow one of the wonderful tutorials from Apple on their iPhone development, focused on simply trying to step through the cycle and get some visible success (Experiencing). I then spend some time thinking about what new tidbit of information I’ve learned (Reflecting) and trying to come up with some way of fitting it my general mental model of how it works (Generalising). I then try it out on my prototype application to see if I truly understood it (Applying).
Having read about the model a while ago, I think there are a few key things to focus on when using this model:
- Keep it small – I could choose to run through all of the different Apple iPhone tutorials one after the other. This doesn’t give me any chance of reflecting, generalising or applying the material. Given my very forgetful nature, working with one tutorial at a time through this cycle is important. I try to keep this cycle in terms of a couple of hours, not a couple of days. Attempt to pick up knowledge incrementally.
- Rinse and repeat – Going through this cycle one doesn’t guarantee you’ll actually learn everything, or even anything. I’ve found I got to the end of doing something and didn’t have any general model. Iterating lets you mine and discover new lessons. I repeat the same exercise, and as I do, I notice I pick up different things.
Interesting it is these two aspects, incrementing and iterating that is at the heart of working in an agile manner. Notice how it’s all about learning then?
I’m a big fan of XP’s practice of spiking solutions. Although I’m not currently doing TDD because I barely know enough about iPhone development to make myself dangerous, I haven’t quite dropped all practices. I still use source control (just a local SVN repository) against the root of my spikes directory.
Here’s how I’ve been structuring myself:
The benefits of this let’s me quickly create new projects to learn a single lesson given the numerous tutorials out there, and then put that under source control for reference code at a later stage. I then spend some time integrating it into the MyPrototypeProject, making small incremental commits as I make progress. The best part is that if I make a mistake along the way, all I have to do is a svn revert -R . to get back to a working state if I get too frustrated or lost.
Late last week, Andy Yates got me onto the whole Hello World application for the iPhone. Since then, I’ve been dabbling around a bit more trying to get my head around it. After having studied how people learn things using models such as Shu Ha Ri, the Dreyfus Model of Skills Acquisition, and Kolb’s learning cycle, it’s fascinating to try to understand how best to pick it up.
Here are some observations that I’ve made so far:
- There are many different dimensions to learning how to write an iPhone application. First, there is the fact that it’s written in Objective C, so you’re learning about the syntax and intricacies of a new language. Secondly, you are learning new development tools including XCode and Interface Builder. Thirdly you are learning about the libraries, documentation, and understanding how things fit together.
- I intentionally recognise myself as being at Shu level (in Shu Ha Ri) or a Novice (on the Dreyfus Model). This means that I want to have some quick wins, get stuff working and worry about how it all fits together in the next stage. I’ve found that repeating the same exercise (almost like a kata) has helped me understand how things relate to each other just that little bit more.
- Writing a journal helps. I intend on blogging about some things that I’m discovering. It might help one person out but it will sure help me articulate clearly my understanding (or lack of understanding) about the topics that I’m finding. When I don’t blog, I’ve got a little text file with snippets on what things I’ve discovered and what things still puzzle me. It’s helping me organise the random things that I’ve got.
- Interestingly, I’m less interested in following some of the practices I would if writing a production application. This means I’m not worrying too much about refactoring or testing until I get the basics down. I don’t want to confuse the concerns of exploration and learning with verifying the system works (which I can barely get going right now). When I am more confident in my knowledge, I’ll definitely spend more time thinking about these things.
Definitely agree with this from the 10 Things I Wish Lean Practitioners Wouldn’t Say in 2010 (via the Lean Blog):
7. “If you can’t measure it, you can’t manage it.”
I don’t believe that statement. I think this phrase should be avoided and it certainly shouldn’t be attributed to Dr. W. Edwards Deming, as it often is mistakenly. Dr. Deming never said this and he, in fact, meant quite the opposite. Some of the most important factors in a system are very difficult, even impossible, to measure. That doesn’t mean you can’t try to manage them. John Hunter, friend and fellow blogger, has the definitive take definitive blog take on this here…
Don’t get me wrong. Metrics are important but they aren’t always most important.
Assuming that people make it to the Covent Garden venue tonight given all the snow conditions, then I’ll be running the Top Ten Secret Weapons for Agile Performance Testing presentation Alistair and I ran at Agile 2009 for the North London British Computer Society branch. Here’s the email detailing it all.
I’m a self confessed keyboard-junkie and avoid using the mouse to do most things. Being new to a mac environment, it’s not necessarily clear how to get some of the usual things done. Inspired by the tip that Thomas wrote here, I figured it’d be worth sharing how I’m navigating my way around. Please leave a comment sharing your favourites!
Enable tabbing to all fields in webforms
The mac apparently wants to make it difficult by default to enter in web forms using a keyboard. Turn on the Full keyboard access option to All Controls. Use the dialog following System Preferences => Keyboard & Mouse => Keyboard Shortcuts page.
Equivalent of accelerator or access keys
Most windows applications provide underlined characters so you can access them with the ALT+<letter> key. In this manner, you can access all items without having to click the mouse.
Mac equivalent: The most effective way I’ve found so far is to use the Help (CMD+SHIFT+?) and then type in the label of the menu item. Use the up and down arrows and enter to select. Note that this isn’t guaranteed to work in all applications (like Firefox opening a help page instead)
Closing windows
Fortunately the CTRL-W option that would close applications maps directly to CMD+W although unlike windows, closing the last windows doesn’t automatically shutdown the application. CMD+Q will do the trick instead.
Opening finder
On windows, I’d use the Windows+E button to open up a new version of windows explorer to look at files. There seems to be a few ways to do this. If you have quicksilver installed, open quicksilver and then start typing Finder. If you’re using spotlight, start typing a file you know exists and then hit CMD+R (reveal in finder).
Unlike windows explorer, finder won’t necessarily always start from the root directory. Use the keyboard shortcuts CMD+SHIFT+H to start from home context or CMD+SHIFT+C to start from the computer context (useful if navigating to network drives).
Scrolling through windows of the same application
Use the CMD+` (backquote) to do so. Use CMD+~ (tilde) to go the other way (or CMD+SHIFT+`)
Show Desktop
On windows, I would use the WIN+M to minimise all windows. On the mac, you can use F5 if you don’t map those keys to normal functions (such as volume control) or if you turn on Expose, you can use F11 to hide all.
This year proved interesting for those in the agile community, or at least for me. The most commercialised agile methodology lost one of its largest figureheads, and a new community of thinkers emerged focused on prioritising a practice often implied or described as optional in other methodologies. What I found fascinating about a new community forming is that in finding its own identity, it naturally results in denouncing ties with existing communities (to a certain degree) and comparisons about whether or not they are “agile”.
This lead me to ask myself, “What is wrong with agile?” To better understand it, I went back to finding out why “agile” first started. From my understanding, a community of thinking practitioners (not just thinkers) coined the phrase “agile” to unite people working in different ways to help identify with each other. The actual methods for working in an “agile” fashion existed well before they coined the term.
I respect and heartily thank this group of thinking practitioners for coining the term “agile”. A simple word acting as an umbrella that encourages people to swap ideas between communities. I recognise this same “vagueness” that draws people together also makes it difficult for newcomers to identify with what it means.
Look at how other communities relentlessly protect their set of practices, branding and declaring you are or are not doing methodology X or approach Y, particularly when reinforced with certification programs. I’ve realised this same protectionist attitude acts as a wall to new ideas spreading between people and organisations that could be beneficial.
I vouch that the term “agile” remains useful. Let us not forget the original intent behind the word. Let us embrace and create opportunities to continue welcoming all thinking practitioners from different backgrounds to connect and swap ideas and experiences to be more effective and successful.
Recent Comments