“I challenged hackers to investigate me and what they found out is chilling” is an interesting article – it’s the story of a couple who challenged a hacking team to pen-test their digital lives. To give some context to the following quote, their laptop has been compromised and user ID and password for their on-line banking account at Chase has been stolen by the ethical hacking team:
Chase.com uses a two-step verification system, which momentarily stymied SpiderLabs’ hackers. Every time she or I logs on from an IP address that Chase doesn’t recognize, it offers to send us an activation code via text to our mobile phones. But a search of Charlotte’s hard drive revealed Chase cookies, which the team copied and used to convince Chase that she was logging in from home.
You could argue that if your PC has been this thoroughly compromised then you have bigger problems, but it still points out how limited some two-factor authentication systems can be if you allow devices to be remembered/trusted.
On Saturday I was lucky enough to attend ThoughtWorks LevelUp EXP at the ThoughtWorks Brisbane office.
As well as plenty of opportunities to chat with the ThoughtWorkers (and Chad!) who kindly gave up their Saturday, there were six presentations throughout the day:
Opening Keynote: Design Thinking
Ben Melbourne (@benmelb) set out to teach us about design thinking, and how it’s important for any project. The main points that I took away from his talk were:
Visual design is only a small part of design.
UX research is not strictly academic or scientific – iterate quickly and rely on feedback to get the best results in the shortest time.
Embrace constraints to get the most out of a situation. Design is harder when you have a green field to work in – if you have constraints, don’t fight against them, use them for inspiration.
Everyone is a designer – if you’ve ever been on a project without a designer, it was you.
Always ask if the current approach is the best use of business capability.
Functional Programming for Fun and Profit
Next up was James Ottoway (@jms_) with a good intro to functional programming. He started out by explaining declarative languages and reactive programming, as well as DSLs and closures and how they can be used to cut complexity.
Declarative languages focus on expressing the logic of a computation, not how to carry out that computation. Regular expressions, Chef/Puppet configuration files, and SQL were all used as examples of declarative languages. In James’s words:
We’re expressing what, not how. And that’s a good thing.
Expressing what you want to do (and not how it must be done) frees up the compiler/interpreter to make decisions about implementation at runtime, and eases the burden on you as a programmer.
When talking about reactive programming, James used Excel (everyone’s favourite spreadsheet application) as an example of a reactive program. This is a really simple analogy which I think helped everyone grasp the idea of reactive programming quickly. He also pointed out that the windows GitHub client is built using reactive programming (using ReactiveUI from what I can see).
As someone who’s trying to learn Haskell at the moment, this section about of this talk about closures was interesting to me. Closures aren’t something that I was seeing in Haskell, perhaps because I’m still battling with unfamiliar syntax (turns out they’re pretty much everywhere). A closure is just a function together with a referencing environment, and they’re pretty essential for functional programming.
Business Analysis
After lunch we heard about the life of a BA from Cathie Hagen (@catherist) and Jiangmei Kang. BAs are an integral part of every stage of a project, and use their place as a bridge between the client and the developers to ensure that value is delivered to the client. The following is a photo I took of the board used to explain the many aspects of work as a BA, I think it says more than I can:
(Sorry about the poor quality – the projector turned on for the next talk just as I was taking this picture)
User Testing
Why build something that people don’t want to use? It’s 2013, doing that is a waste of humanities potential.
Pete Chemsripong gave a great talk about the importance of user testing. Speed is important for user testing and ideally
should be a daily thing. Every feature that you’re working on in a project should be validated by a user (this agrees
with what Ben said in the design talk).
Helping you get your first job
The last presentation before the keynote was by Jean D’amore (@jeandamore) with an entertaining talk on how to land your first job in IT. The talk introduced job hunting as a game where you can’t control everything, but what you can control can make all the difference. He split the journey into seven steps, each accompanied by a great movie reference & quote. Hopefully the slides will be made available as I didn’t get everything down, but what follows is my summary:
Yourself (The Last Samurai)
Improve the environment by working on yourself.
Do: know your boundaries, be versatile, stretch yourself, maintain balance, listen, commit to projects, be willing to sacrifice, learn/do new things
Don’t: underestimate yourself, thing you’re alone, deny the challenge, limit the horizon
The Search (An Unexpected Journey)
The search will change you
Do: know what you seek, choose a domain, know the employer, ask about graduate programs/training, keep your LinkedIn (and internet presence in general) up to date, favour simple job ads (i.e. not ads that list every skill under then sun – you often need to be a specialist before you can generalise)
Don’t: dismiss too quickly, use recruitment agencies, work on projects you don’t agree with (everything you do has an impact and will impact you), waste too much time searching on-line (do spend more time talking to people)
Your CV (The Colour of Money)
Do: PDF it!, make it unique, know what’s on it, web design it (use web design principles – e.g. readability, don’t cram everything in), make it one page, get friends to read it, start with skills over education
Don’t: lie/exaggerate, rush it, use ‘bullshit bingo’ words (except in a few cases where it’s in the ad – in this case, always explain and give examples)
Applying (Close Encounters of the Third Kind)
You need to understand and be understood
Do: strike with precision, add a cover letter, apply to people (not computers), customise your CV, wait, follow-up, be organised
Don’t: bulk apply (do apply to at most 5 organisations at once – it becomes too hard to keep track of what you’re doing otherwise)
Interviews (Gattaca)
Little things are often the most important. For example, be good to everyone at the company.
Do: look clean and tidy, research the company & their interview process, arrive early, know who you are and why you’re there, know what you’ll be asked, listen, ask relevant questions, be humble and curious, know your stuff (especially your résumé)
Don’t: be afraid to ask for clarification, lower your guard until you’re clear of the building (i.e. do treat every moment you’re in/near their offices as part of the interview), ask how you did at the interview, ask about time/money when you’re after your first job, leave your phone on, have alcohol (even if offered), go if you’re sick (you need to be 100%, and the interviewers will understand)
Hearing Yes/No (The Hurricane)
Don’t be afraid of failing and keep bouncing back
Do: take your chance to explore/re-evaluate, take risks, trust your instinct, understand that this is one step is a career
Don’t: burn bridges, take it personally, rush to accept, say you’re waiting on another offer
First Day (City Hall)
Make a difference and work where you’re satisfied. Focus on employers that give you the upper parts of Maslow’s hierarchy of needs
Do: learn names, go to social events, pair, do what you’re told, be helpful, learn the ropes step by step, leave if you don’t like it after a month of so
Don’t: panic, try to change things quickly, cold shoulder anyone
Closing Keynote: Who are you, where are you going, and how will you get there?
The closing keynote by Chad Renando (@ChadRenando) followed on nicely from the presentation from Jean, and was really a step back, focussing on making the most of who you are, being clear about where you are going, and being intentional about how you can get there.
Every man invents a story for himself – which he often, and with great cost to himself – takes to be his life.
Chad used this quote from Max Frisch as a way of explaining that you create your own story, but you should never think that it can’t be changed or even completely rewritten.
You need to understand yourself to understand how you will work with others – are you more practical or creative? Do you approach things in an analytical way or listen to your beliefs? Are you structured or flexible? Learn what your signature strengths are and use those to create a mission statement, as your strengths are the things that make you feel alive. At the same time, look out for the strengths that you rank poorly in.
Create goals (what is your 9-day plan? your 120-day plan?) that align with your strengths, but don’t think that these goals are set in stone. Use goals as a way to direct yourself, not as measures of success. This allows you to iterate on your goals and improve them as you learn more about yourself.
Chad finished the main part of his talk with his axioms from life in a digital studio:
Ask questions
Focus on resolving process conflict, not relationship conflict
There are things that are understandable, but not acceptable – don’t get the two confused
Everyone is generally doing the best they can
There is no fault, only cause
Every conversation we have is with ourselves, and sometimes they involve others
If you want to lead others, lead yourself
The day covered a range of topics and gave me a lot to think about. One point that appeared a couple of times throughout the day (and which Chad reiterated at the end of his keynote) is how important it is to get involved with your community. It allows you to grow your network, get references and learn. I can’t agree more, I have learnt so much and met lots of interesting people by attending the YOW! conference, YOW! nights, and the BFPG & Brisbane GPU Users meetups (there are tons of similar user groups in Brisbane – I guarantee you won’t regret attending one of their meetups!). Another way to get involved in the broader community while sharpening your skills is volunteering – there are plenty of non-profits that could use help with IT. Or, if you have an idea/are working on a start-up, River City Labs is building an amazing community of like-minded people.
Thanks again to ThoughtWorks for running this mini-conference – you’ve done a great job of inspiring this IT undergrad! More about ThoughtWorks LevelUp can be found on Twitter (@TW_LevelUp) and Facebook.
There are some interesting responses, pointing out that comments are great for references and in-line diagrams, and sometimes necessary for code that has been restructured to improve performance (although creating difficult to read code solely for performance reasons is a separate issue).
It’s just amazing how many mistakes [are made] and how bad programmers can be. Everything that is syntactically legal, that the compiler will accept, will eventually wind up in your code base. And that is why I think static typing is so valuable.
John Carmack (full talk here – note this link jumps to this quote – part one of the keynote is here).
Pretty much sums up how I feel about the static v. dynamic debate for anything other than very short-lived prototypes.
I recently watched Brian Beckman’s Don’t fear the monad talk (YouTube version here) and thought it was a really good explanation of functions, monoids & monads and why they’re a useful way to master complexity.
I recommend it to anyone who’s starting to look at functional programming. Here are some of the key points I took away from the talk:
Functions are data
A function takes an argument(/s) and returns a value, and always returns the same result for the same inputs
Think of a function as a table lookup – the table is the data
Functional programming is a style that can be used in almost any language
But some languages make it easier than others
First class functions (or at least lamdbas) are a must have
Complexity is killing software developers – we need to control it
The best way to control complexity is to put functions into groups where things are disciplined, and where they can be composed in arbitrary ways
Build complexity out of simplicity by composing things
A monad adds some data to a value, and the implementation of the bind operator defines how that data interacts
If you want to add a feature, you shouldn’t even have to know what you’re going to interact with
Using monads means the interaction is already built into the structure
You don’t need to know what a monad does
So long as it follows the rules, it can have arbitrary side effects
Another interesting part was Brian’s reasoning about why functional programming is a ‘hard sell’:
Immediately upon the foundation of computing, the world split into two camps – the bottom up camp and the top down camp.
The bottom up camp is typified by Turing machines – “let’s start with the hardware and add abstraction as we need it to get close to the mathematics, but never at the expense of performance”. That gave rise to FORTRAN, C, C++, Pascal, Java, C# … all of those languages are in that tradition.
The top down crowd says “let’s start with the mathematics and subtract abstractions to get down to the machine, sometimes at the expense of performance”. That tradition starts with lambda calculus … and only subtracts abstraction when it is convenient to do so. That’s the tradition that gave rise to ALGOL, Lisp, Smalltalk, ML, Haskell and all these languages that have reputations of being slow.
As most programmers are familiar with the bottom up way of doing things and the two approaches come from very different origins, it can be hard to convince a bottom up programmer of the benefits of the ‘top down’ approach. It can be even harder to pick up functional programming once you’ve resigned to giving it a try.
[The top-down crowd] are saying “don’t go to the hardware so early, you’ll lock yourself into irreversible design choices”. [The bottom-up crowd] are saying “don’t give me all this math, I can’t handle garbage collection, or function calls or whatever it is that’s getting in the way of my performance, I need every ounce of performance the hardware can give me. And I’m willing to write software into the wee hours of the morning to get it”.
The last sentence here is what stands out to me – as software gets more complex, it seems that bottom up programming is going to require more and more time working in the wee hours of the morning to get the desired performance and functionality.
