Your SlideShare is downloading. ×

Raising The Bar

816
views

Published on

A Short presentation given at the London Java Community on Raising the Bar for yourself as a technologist.

A Short presentation given at the London Java Community on Raising the Bar for yourself as a technologist.

Published in: Technology, News & Politics

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
816
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Raising The Bar1Thursday, 2 May 13
  • 2. Hacking Yourself• We’ve taught & mentored a lot over the years– Ben Evans (@kittylyst)– Martijn Verburg (@karianna)• Culminating in the LJC, of course!• The most amazing thing about the human mind is itsability to change & to alter itself• The industry moves so fast– We need techniques to keep up– Staying curious is key2Thursday, 2 May 13
  • 3. How Do We Learn?3Thursday, 2 May 13
  • 4. Cargo Cult Teaching?4Thursday, 2 May 13
  • 5. How Do We Learn?5Thursday, 2 May 13
  • 6. How Do We Learn?Self-studySocialcodingFormaltraining6Thursday, 2 May 13
  • 7. Use A Basic Toolkit• Ideal way to teach ourselves• We should know all know basic CompSci– Use it on a daily basis– Look for places to apply it• What should be in our toolbox?– Data structures, Big-O, type theory, information theory– Compilers, interpreters, virtual machines– A proper understanding of Unix– Operating systems & kernels– Hardware, wherever possible7Thursday, 2 May 13
  • 8. Check Your Working• Check your working• Verify your results• Have your peers to replicate your results– Do NOT just reuse others conclusions blindly"The first principle is that you must not fool yourself—and you are the easiest person to fool.So you have to be very careful about that. Afteryouve not fooled yourself, its easy not to fool otherscientists.You just have to be honest in a conventional wayafter that." - Richard Feynman8Thursday, 2 May 13
  • 9. Explicit Assumptions & Approximations• State– How much data?– How many concurrent users?• Document– Work with other stakeholders– Discuss with peers– Formal document as a project artifact• Revisit– Sanity-check every once in a while– Verify that initial assumptions are still met– Update if not9Thursday, 2 May 13
  • 10. Reduce The Problem• Wherever possible, try to decompose the problem– Use approximations• Build simpler versions if you need to– Can add complexity later– “What is the simplest thing that could possibly work?”• Spend time thinking about the problem domain– Very few projects are really “shipping widgets”• Graphical techniques are powerful– They don’t need to be complex10Thursday, 2 May 13
  • 11. Use Diagrams11Thursday, 2 May 13
  • 12. Simplify Your Coding• Naming– Strict adherence to SRP– The name should encode SRP– Reject a commit if this is not adhered to• Complexity has hidden costs– No class is more performant as one which isn’t there• Reduce Technical Debt– “If it hurts, do it more”– Technical debt accumulates faster than you realise12Thursday, 2 May 13
  • 13. Be Aware of New Developments• But evaluate them on their merits– Too easy to let Hacker News rule the roost• Make empirical technology decisions– Basic toolkit & empiricism help here• Newer is not necessarily better• Don’t blindly using others conclusion• “Why Devs Keep Making Bad Technology Choices”– Google & read it if you haven’t13Thursday, 2 May 13
  • 14. Share What You Know• Know where to get more information– Especially from other people• Teach what you know to others– You don’t really know anything untilyou’ve taught it to someone else• Teaching others also teaches ourselves– Re-examine the basics14Thursday, 2 May 13
  • 15. Share What You Know• Try out lots of ideas & subject areas• Don’t be afraid to be wrong– Or shown a different point of view• Do expect SMEs to prove their assertions• Avoid Rhetological Fallacies– Especially “Appeal to Authority”• Seek out colleagues & people you like working with15Thursday, 2 May 13
  • 16. Be Inquisitive & Be Yourself• Travel, learn to speak new languages– Domain, Human & Computer• Diverse problems feed the mind– And it’s more fun• Development is a social activity– Probably more than technical16Thursday, 2 May 13
  • 17. Summary• Build a mental toolkit which is simple– Focus on fundamentals– Use visualisations & graphical techniques• Use empirical data extensively– State your assumptions & approximations• Share what you know– Teach & mentor your peers & younger developers– Constantly relearn & reteach the basics– Look for puzzles everywhere• Be yourself!17Thursday, 2 May 13
  • 18. Current Course Ideas• Advanced Java - London May 25th• The Java Virtual Machine - London July 6th• Introduction to Finance & Financial Technology• Linux / Unix for Java Developers• UI & UX for Java Developers• Java 7 / Java 8 features• What do YOU want to see?• When works better - weekdays? weekends? evenings?• Grab a drink & tell us your thoughts...18Thursday, 2 May 13
  • 19. Over To You...• Twitter: @kittylyst @karianna @DeveloperFocus• Email: ben@jclarity.com martijn@jclarity.com• Web: http://developerfocus.com/19Thursday, 2 May 13

×