Minimum Viable Pundit: What went down at Front-end London 12

Quite a lot, it turns out

Front-end London is an evening meet-up of lightning talks hosted by Made by Many and held at their stunning offices that’s dedicated to front-end development. The format is three lightning talks, and they keep it fresh with a good mix of both technical, philosophical and visually interesting talks. 

Before the talks there was a brief (read: disastrous) attempt at a Google Hangout with FEL founder Chris Bell who took off for the US a few months ago, which was interesting.

Anyway, enough jibber jabber from me, you came for the talks, so here they are.



Adam Rogers, How to win designers and influence developers 

First up was developer Adam Rogers from Mint Digital, talking about his first experiences at Mint in a product manager role and the difficulty of ‘working with people without getting lynched’. Adam explains that his experience with computers couldn’t prepare him for the difficulty of handling people, but that a big part of software development is dealing with people. 

As he puts it, 

‘Computers are easy: tell Git what to do and it will do it, but people might argue with you. they have baggage like feelings and weekends.’

Happier teams build better products, says Adam, but he concedes that he isn’t the best at this. He recounts having a bad project, as a project manager where the team were missing deadlines and he hated everyone and everyone hated him. He quotes the old saying, ‘You can delegate a task, but you can’t delegate a responsibility.’ Alex takes us through what he’s learnt about better managing technical teams.


#1 Stop criticising

Alex says we need to stop criticising. No more ‘Why? Who? Why are they an idiot?’ Parts of the culture, like calling it Git blame are not helpful. There’s an onus on blaming and it needs to stop. If there’s one thing Alex has learnt from Hacker News it’s that when there’s a fight between developers, no one backs down!

#2 Credit where it’s due. So give it.

#3 Communicate needs

You shouldn’t be afraid to explain the problem, and then you can easily get it fixed. Just because you are in charge of the team, you should be able to ask the person with the expertise to solve your problem.

#4 Ask questions

Homework

Yes, Alex set homework. He said to give credit when you want to scream, and to help someone fix something, or at least through the process of fixing something.



Where Daniel hangs out

Daniel Grant - Explorations in 3D Space 

Daniel was the first speaker at FEL to send in a video to explain what his talk was going to be about (we didn’t get to see it unfortunately), but we do learn that he’s a freelance front-end developer and that he’s going to be trying to take us on a ‘journey through space itself’ to discover the potential of some of CSS3’s lesser used properties and uncover the mysteries of its 3D spec.

Daniel opens with the caveat that 3D CSS is awful, a terrible thing, that has turned the front page of Codepen into a Dribbble for CSS devs. He elaborates on his space analogy by explaining that he’s going to be showing us some useless examples of CSS things, but like space exploration, we don’t do it because its useful but because it stretches our understanding of technology and what we can achieve.

CSS3 gave us properties with which to manipulate elements into 3D shapes, some of which Daniel begins to show us, with some *eek* live coding! For this reason, I have to apologise to Daniel in advance, there’s just no way I could do his talk justice transcribing it here. 

Anyway, onwards! He begins:

.title

transform;translateY(-180px)


.title

transform;rotate(30deg)

Daniel explains that this is still 2D, so let’s do something 3D. He adds:

transform;rotateY(30deg)

... to what he has already.

But it still doesn’t look very 3D! 

At this point he adds the property perspective, which is crucial for 3D, as without it we don’t know how near or far the person is from the element. He uses the perspective to masterful effect to recreate the scrolling text intros of the Star Wars films. 

Cue riotous applause. Insert your own geeks/fish/barrel analogy here.

2nd demo

In his next demo, Daniel recreates an old 3D CSS demo of a spinning plane, one side red, one side green. Cue some quite ‘Oohs’ from the assembled throng, who are all clearly now drunk. 

At this point he explains that IE11 doesn’t quite have all the right 3D CSS spec, so in the case of IE, you need to have an attractive non-3D fallback.

3rd demo

Daniel creates a very impressive (to my non-3D CSS literate eyes) model of a planet orbiting a star. He follows this up by making an entire solar system, but the illusion of 3D is limited because he has flat objects rotating on one plane around another two-dimensional object.

At this point Daniel is really through the looking glass of 3D CSS, and I’m reminded of the mad things people were doing in the early days of Flash. The inevitably slow frame rate of 3D CSS makes for some unique difficulties however. 

Daniel preempts the question, ‘Why not use 3GS, or OpenGL?’, by restating that it’s interesting to push the limits of what’s possible with a language to increase our understanding of what can be achieved. We’ve still got some way to go before the implementation is where it needs to be, to open these ideas out into smooth experiences.



From Tim’s awesome blog

Tim Ruffles, What is code quality? 

Event organiser Ilya explains that Tim actually has two talks he could potentially give and we can vote for which one we want to hear. We can either hear Tim’s planned talk on code quality and what it means, or one on the Vim buffer and how he’s slowly learnt to love Bash, which apparently consisted of 35 lines of code. Clearly in no hurry to get to the pub, the majority of the audience opted to hear his code quality talk.

Initial thoughts: code quality is meaningless!

Tim suggests that a lot of what we think of as code quality is hopelessly subjective, but he defines his terms slightly by saying that code quality is everything the user can’t see. Code quality angers colleagues, not users. So what is good code?

Tim suggests this is like asking, what’s a good film. He wonders how a film can be 4 out of 5 stars for every person, and suggests that it’s pointless: it depends on the person. He appears to be sleepwalking into a flawed analogy but explains that there are some objective standards, like flaws in the plot, or shots out of focus. What ‘quality’ means can depend on us, unfortunately we are talking about technology:

‘although programmers often think of themselves as almost autistically rational people, they are actually absurdly faddish and emotional people.’

And out of this morass of subjectivity, code quality is the most subjective. 

For example, for Tim, the languages Haskell is really hard, but then someone came along and made Idiomatic Haskell, and explained how many many lines of Javascript (which Tim spends a lot of his time writing) can be written in just a few lines of Haskell.

Can we leave taste aside?

1. concise

2. simple

3. readable

4. extensible

5. testable


#1 Concise:

So, starting with concise: ‘A sentence should contain no unnecessary words, and a paragraph no unnecessary sentences.’ So don’t repeat yourself! (shortened to D.R.Y.). But how can we track this?

Tim suggests Flay - where you can rack two bits of Ruby code that are doing the same thing logically, even if they aren’t structurally the same. You want each fact about the system to be captured once, in a single point of truth (Tim calls this S.P.O.T.)

#2 Simple.

Tim concedes that nobody tries to write complex code, but simple is a tricky word, we should abandon ‘simple’ and ‘complex’, as they are relative and contextual and more often than not, subjective. 

Tim posits Rich Hickey’s definition of simple: doing one thing well. So what can we do with that definition of simple? We should have a low number of concepts, and low body of knowledge. Keep it in one language, and therefore one concept; once you’ve grasped that, use it everywhere.

#3 Readable

  1. Be careful with idioms, or bringing idioms from other languages with you to the codebase.

2. Good naming makes for good code. Remain consistent, so avoid abbreviations.

3. Replace trivial comments with variables or functions that describe exactly what it does, because you can’t ignore them: comments are not documentation!

4. Put in example code, tests are good! (a sentiment I have heard echoed elsewhere)

5. Give explanations of the system at a high level.

#4 Extensible/reusable

Tim suggests that this happens a lot less than you think, and that code being reusable is not good per se. There’s a good chance this problem is specific to your app, and you can get yourself in all kinds of mess trying to make it work somewhere else on something else. More generic does not mean more usable. 

#5 Testable

Tim has pretty much covered the different ways that you can make your code easily testable, such as having few dependencies, and having code be relatively independent, but goes further by saying that this is where you should start when trying to determine if you are writing good code - can it be easily tested?



The Front-end London events happen once a month a Made by Many’s beautiful canal-side offices near Angel in London. See you at the next one!

Image credit: Edward McKnight Kauffer (1890-1954) Soaring to Success! Daily Herald – the Early Bird 1919 (as reproduced on the Made by Many office’s wall.