edX - Leadership for Engineers

Leadership is hard right. It's really hard for software engineers as well because you move from a tangible output each day (in terms of LOC or user stories or whatever metric you love yourself) to something a lot less tangible. Have I coached well today? Have I lead people down the right path? Is everyone happy and are they growing/developing?

You know what else is hard Leadership training that actually resonates or hits home hard. It can feel like a lot of fluff and buzzwords and lack anything that you feel is directly applicable to your day to day challenges and that's probably because your day to day challenges are now a bit more abstract or 'softer' than they were before and there's no 1 size fits all approach for that. The training normally ends up being focused on trying to draw out your empathy and patience for the most part.

I've done some leadership training before in the company I work for and whilst it was useful (and the guys running the course were very good) it probably didn't lead to that community of people getting together to discuss the challenges and successes they have. I wonder if that was because we all worked together and most of the things we would be talking about may have been directly or indirectly linked to each other

I also was on a course here in Ireland called Fusion which was graduates working on high value projects in conjunction with academia. That was great because it had a residential element and people were from all over. Unfortunately my involvement ended prematurely because the company I was with closed down!

So I was really interested when EdX emailed out their newsletter and included in it was a course by

Delft University of Technology on Leadership for Engineers. So self-paced remote leadership training, god they really are making this hard for themselves! You cannot accuse them of not investing time and effort into the networking aspect. There is an Interactive Map and Teams and Facebook groups etc. It's an interesting concept and I guess they are maybe indicating that the networking quotient of leadership training is as important as the content itself.

This probably sounds weird but I think there's a lot of parallels to be drawn between leadership training and ante-natal classes. You will get an overview of things that are going on but really it's about trying to centre you and give you the confidence to trust your own instincts and get on with it as much as possible.

Possibly naive thing to say but it feels like your own personality and traits will come out in the leadership role so the best thing to do is be self-aware and know what your own bias and what you're good and particularly bad at. That's something they touch a little on here.

In terms of this training itself - it is pretty good. They use case studies such as a mayor who is having issues, it's interesting but maybe a bit cheesy as well. It's a scenario in which a 'analytical' argument is being undermined by political games and how to get around it. I think that's something that will scare a lot of people coming to management/leadership so it is an interesting area to talk about. It then tries to tackle the analytical mind of engineers and how situational management is and how the two may not be compatible often.

They also try to cover some of the traditional coaching/management training that normally happens face to face. They talk a little about it in week 2. You get the impression this is also partly a research project for the university to see if this type of leadership training is possible. It's clear with all the effort they've made to get engagement and interaction between participants that they really are trying something.

A lot is made of the multi-game option. I still find the logic of muddying the waters to be confusing but I'm a bit simple so that's ok.

There is a focus on engineers and the mindset a lot of engineers typically have and how that may impact their leadership abilities. All in all the course is a useful step for people wanting exposure to some leadership training but aren't willing or ready to go all out for a MBA etc. This will never replace or rival that MBA but I think people will find it of some use.

There's a good section on personal management in terms of looking for stress, being optimistic and choosing your response wisely. It's an interesting point and the course evolves from there into being about managing your career and goals.

This course is free to Audit or you can pursue a certificate for $50. Take a look and see, I would definitely recommend checking it out

Pluralsight - Getting Started with Polymer

I manage a UI team who are undergoing an upgrade to use Polymer. I've read up on the topic a bit and read about web components in all their magical goodness but wanted to spend a little time doing something hands on as well as scoping out potentially good training resources for people in other teams and that's when I stumbled upon  Bill Stavroulakis and his Getting Started with Polymer course on pluralsight.

It's a really fun course. It is for beginners, which I feel I am, and skims the service but it really does cover all the important stuff in a pretty fast paced way. Bill is a great tutor on it because he gives off a really gentle and relaxed vibe. I think it's exactly what you want when you're new to a technology and some of the concepts.

Lots of great examples. Explanations always forthcoming and introduced me to Plunker which is a really interesting site.

The only downside I would say is the course isn't really < 2hrs. There's a lot of 50 second videos with links. It's great though so it's not really a complaint but budget a little longer to get through it.


Being the great bunch of lads that he is, Bill has already got a follow up course that builds on this introduction. I'll be hopefully giving that a go very shortly.

If you have a pluralsight account and want to take a look at the leading web component library I think this is a fantastic place to start.

Quick Book Reviewd : IOS Build and Release and Release It!

Quick Book reviews. I have read a few but keep ending up starting another one before I post a review so attempting to put that right

Essential IOS Build and Release

So I've never built and IOS application or used XCode but was interested in the build/release cycle for apps so decided to read this book.

I know then I'm not really the intended audience of this book.

It's a pretty solid introduction. Was hoping for a little more insight on CI/CD and testing and whilst it does touch on some of it, it doesn't feel like it ever really gets going in that regard. Much more a hands on tutorial for walking through the process

Release It! by Michael Nygard

Not much to say that hasn't already been said. This is the bible of resilience and avoiding failure. It details patterns to follow and has real tangible advice. If you haven't read this and you're interested in how to build distributed complex systems that aren't going come crashing down around you... you probably should

BelfastGophers Meetup

So of my Resolutions the one I've been worst at is going out and getting involved in the community via meetups etc. I've been to a couple so far this year and a conference (Agile in the City) but I know it's something I need to do a bit more of.

I've been tinkering with Go a little bit in my own time and really enjoyed it so I was really excited about the chance to go and talk to people who are using it as part of their day jobs as part of the Belfast Go Meetup.

I mentioned to one of the organizers that what I love about Go is that it feels like a dynamic language and in a lot of ways it reminds me of Ruby (I know! I'm a heretic). He told me that everyone he talks to identifies or associates go with their favourite or most used language. Not long after one of the speakers mentioned how easy Go was to pickup from Python and he felt there was a lot of similarities...These guys know their stuff.

So the actual meetup was an introduction to Go including setting up and installing. We covered the hello world before moving on to an echo application dealing with user input and then using the standard library to build a web server and lastly a putty like client. The progress over the night was great and the explanations were sound.

I had done a few of those things before myself but it was still nice to touch on them again and hear the explanations for some things. One of the reasons I enjoy getting to these events is the sometimes tangential topics that come up. Some of the ones that came up and will send me off looking for

Glide - Was mentioned as offering a dependency management solution for Go but it's something that's a little fractured in the community
Podge -  Seems like a scaffolder like yeoman but maybe a little lighter on function
Club-Mate Cola - I'm a weirdo who is very very into his soft drinks. The hosts of the evening, Farset Labs, had a number of drinks from Club Mate. Whilst I didn't quite get near them or the pizza they are on my list for next time :)

So long story short, if you're like me and normally a little wary of actually going to these events don't be. Everyone is friendly and there for the same reason. If you're in Belfast there's another Go Meetup next month and I'll hopefully see you there! If you're not in Belfast make a beeline for your local go meetup and experience a language that's an absolute joy to play with

A/B Testing

A/B Testing

What an introduction to this book. It starts with reference to the Obama campaign an how A/B testing was used to help drive results there. Wow. Got my attention. Then we get hit with a reference to the Optimizely product that the author helped create to try and offer A/B testing as a product as a lot of companies build something bespoke to manage it. You very quickly get the feeling that the author knows this subject very well

So I came in to this book with some background knowledge on what A/B testing is. For those who don't have that it's when you experiment with a few variations to a random sample of your user base. There has been an explosion on blog posts on this from many sources, one of the most telling for me has been LinkedIn who have put up a number. It seemed like A/B testing was one of the biggest tech buzzes of 2015 with a lot of companies really starting to share information about their proprietary implementations

A/B Testing is something that has really appealed to me in recent times since I started managing the UI Library team in work. I think the flexibility that comes with A/B testing sounds almost too good to be true and I would love to put that into the hands of our team. I also would love for us to be a little more metric driven, that makes me sound like a jerk manager... the fact still remains I would like a little more metrics in the day to day to help guide decisions and reflect on previous decisions.

When mentioning A/B testing before I was told by some colleagues that as we are an administrative website changing customer behaviour wasn't necessarily the most important thing to us. Our users NEED us  day to day to acheive something they have to do, this isn't a social media thing when the behaviour is optional and we're looking to encourage it. Our application suite is moving away from these administrative automation workflows and more into collaborative value add interactions. This changes the way we interact with our customer in some ways and as such I feel like A/B Testing
offers us something we NEED now.

This book offers a lot of insight in terms of getting organisational buy in and applying correct analysis of the data.My takeaway from this book was that if you want to do A/B testing then it's incredible important that you  know what you are looking to improve. What do you do? What are you looking to do? If you don't know that how can you create tests that will help you to that goal


Have you had any experience of A/B testing? I would love to hear from you on twitter or right here in the comments section!

Book Reviews - Lean from the Trenches and Managing Oneself

Lean from the trenches

This is an excellent book by someone who is a fantastic advocate of lean. Henrik Kniberg has been involved with Spotify, were he introduced the team health check concept, and Lego amonst many others. This book deals with a government project for the police force and he talks through real examples and real experience about how they managed to deliver it on time and on budget. Catch him talking about the topic on vimeo

I cannot recommend this book highly enough. Go read it and the many other excellent pieces of information he's given out.

Links to some of the excellent things he's produced with Spotify

• https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
• http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify 
• http://blog.crisp.se/2016/06/08/henrikkniberg/spotify-rhythm
• http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp

Managing Oneself

This Harvard Business Review essay is on taking responsibility to manage your own career as the workplace has evolved a lot since people would stay at one company for 40 years. Short read but with some resonating questions which can be summed up as being very open with self evaluation and knowing what it is that motivates you and what you can bring to the table.

Definitely worth a read for anyone who is feeling a little aimless

Habitat.sh

I am a big Chef fanboy. It's not something I hide very well or attempt to hide. Chef was a huge part of my role within a release engineering team for a few hours and I think that using it has made lots of positive impacts to the organisation I work for as we strive towards continuous delivery.

You can imagine my giddy excitement then when the current Release Engineering team managed to snag a few Chef employees to come into our office to talk about their new product habitat. Also I'm really struggling to get out to events this year and that's probably one of the career resolutions I've struggled with the most.

Nathen Hervey and Thom May gave us a an overview of the solution and it was great. They have a fantastic interactive demo you can walk through in your browser on their site as well so go and take a look at that.

I'll try to give a brief thought on why Habitat is so exciting. Chef has a node orientated view of the world. That's where the rubber hits the road and things like runlists and recipes get applied and attributes get levelled out and that's brilliant for a lot of applications that people run or for infrastructure servers but it does muddy the waters a little when it comes to distributed services and the clusters that offer that service. That's where Habitat comes in with it's gossip protocol to spread config updates and the supervisor to manage the processes you are getting considerable value add over Chef.

There was of course ways to try and bend Chef to work with these services. We had for example many clusters of couchbase servers that fulfill different behaviours within the same environment and so we used the Role concept in Chef to manage that. That was because for the most part the install was the same but there was some config (other cluster members) that was what differentiated one cluster from another. Using roles allowed us to dynamically discover other servers that existed in the cluster but sadly didn't alllow for us to update all of them at once like Habitat is built for.

The one question I have is how this is going to interact with Chef and other stores in terms of forming an open source toolchain that will allow for you to manage and deploy modern distributed services. Most of the demo we saw involved manually pushing messages in using the gossip protocol (which is used in Ubers RingPop) and so I'm guessing you could probably have Chef Providers or similar which would allow you to do that. I would guess you want to have your config that you've just pushed to your production cluster stored somewhere... Also the attribute precedence setting and levelling in Chef is GOLD so you would really want to be able to hook back into that.

I am feeling pretty excited about the opportunities that habitat.sh can bring to us so much so I've started learning Rust so I can attempt to contribute something to the product.

An Evening with Kanban - GDG Dublin

Few months into the Career Resolutions I set for myself and I'm struggling with 1 in particular and that's going to events.

So it took me until April to go to my first one and I ended up travelling all the way to Dublin with some colleagues to attend an evening with kanban in the Google Dublin offices which was being put on by the Google Developers Group Dublin (god love them they have google+ account as well) and Lean Kanban Inc.

I always find the networking part the hardest at these events. Always have and probably always will. I decided this time I would engage a stranger in conversation so after grabbing a cookie I decided to attempt my icebreaker. "I know we Can Ban, but I think the question is should we because you know censorship" (yes I know, I know it was terrible but I didn't have much time to think of a kanban pun so leave me alone) it was met with confusion and then they just sort of looked away so I scampered back beside my colleagues as a single tear strolled down my cheek. As Drake would say "No new Friends" :( I can't be the only one to struggle with this right?

Next time maybe I'll try and be a grown up and ask how people find using Kanban, I just feel like if you can't accept me at my worst you don't deserve me at my best...

The talkers were from Paddy Power and David Anderson who wrote the book on Kanban, no he actually did. Paddy power told us about their personal journey and an overview of their working process and it was all very inspiring with delivery pipelines and autonomous co-located teams hammering value out left, right and centre.

David Anderson took us on a journey of his own introduction of Kanban in a U.S telecoms company before going over some kanban design patterns that he's seen in the wild. 

The talks were great and they reaffirmed for me the reasons why at NantHealth (formerly NaviNet) we use Kanban. I think every now and again it's good to take that step back from what you do every day to see how other people are evolving their processes and increasing their value add and really trying to get back to brass tacks of why we went on that journey in the first place.

So small social embarrassment aside it was a really worthwhile journey from Belfast and a big thank you to the organizers and presenters for such a slick overview.

Book Review - The Tipping Point

I just finished reading The Tipping Point by Malcolm Gladwell.

It's a book that tries to quantify and explain what it takes for an idea or concept to go mainstream or viral. In tone and theme it feels similar to Freakanomics but not as fun. I think this is the loosest book I've read this year which I consider to be career related. I always think it's interesting how some ideas you love don't cross over and other more throw away ones somehow do. I hoped this book would give some insights into how to prepare your ideas or make them more palatable.

Gladwell has a number of concepts he feels explains how ideas move, evolve and take hold and each of those is backed by a case study from the 90's ranging from Airwalk to Hush Puppies and beyond. I'm a little disappointed the 90's examples aren't Sunny Delight and Melissa Joan Hart because to be honest I still can't explain either of those.

The book covers a number of topics like personalities involved in idea's going viral, how to make your message sticky and how context is king. Each time we get a detailed case study and numerous callbacks to earlier ones. It feels like the overall narrative is a little forced. The book offers a lot of insights but I think they are dulled by trying to tie them together into 1 strand.

All in though the book felt long and by the time I got to the part about smoking I was really done in. Even that section has some interesting thoughts and asides but I didn't feel like many of them were actionable. A sense of how these things happened is great but a lot of the time the examples felt so specific that it was hard to pull them into something that is applicable to your day to day challenges in work. The thoughts on making the idea sticky was probably the closest as the maven, salesman and connector thing feels like it's something you either are or aren't.

Would be interested in seeing some of the same analysis put to things like the Ice Bucket Challenge or some modern examples.

Because if we don’t learn from History Channel… we are doomed to repeat History Channel.

Test Automation Snake Oil


This is from 1999 and yet is still so relevant to challenges we still face with Test Automation. Go read it. It's 6 pages and doesn't need a review so instead below are some thoughts that I had from reading it. Surprisingly little of it has dated aside from probably an advance in tooling allowing for more tasks to be automated. This is still evolving today and hopefully I can get a post up about the field of cognitive or visual automated testing soon.

I have a little experience in a QA role. It was the start of my career and it was a mixture of manual and automated testing. I even ended up developing an internal automation framework when I had just graduated so I do have an interesting in Software Testing but do not in any way claim to be an expert in the field. I think Quality is the responsibility of everyone on the team especially when you have a setup, like we do in work, that places the QA Engineer/Software Engineer in Test within a small feature team. I feel that in a role in Software Management it's a massive part of the role to still be a big ambassador for Quality even if you aren't in affecting the code on a daily basis.

I think the drive to automate all the things is coming from a really good place but do worry sometimes that we charge head first into battle that it's really easy to end up in a position with a mass of tests which make it a lot more difficult to evolve our application and release features than they should. That's before you get into the challenges associated with maintaining all the LOC that you've just generated to create those tests or the terrible fear of over testing because sometimes it gets confusing between what you can test and what you should test.

So when you read that in 1999, "In fact, in my experience, they fail more often, mainly because most organizations don't apply the same care and professionalism to their testware
 as they do to their shipping products." shouldn't it hurt and surprise us that sometimes we're still making those mistakes. When you read that Boreland in the 90's (shout out to the Silk Test massive)
correlated if bugs were found by automated or manual testing it makes you wonder if we are still even doing that as an industry now. Can we point at something and state that we know
how well the automated tests are performing?

In a world of flaky tests or tests which need changed with every single code check-in (those not impacting external interfaces included) shouldn't we be looking critically again at R.O.I on each automation endeavour in the same way we should do with every user story we write? Does having a suite of tests even stop us from doing the appropriate manual runs in that area? Does a false sense of security exist?

The most important thing that test automation is meant to do is free the resources you have from doing mundane repeated work and using their brain and insight to find the unexpected. The big concern should be if we set up our test engineers to spend all their time writing automated tests are we really setting them up for success? I think it's only fitting to leave with one more quote from the article "That's why I recommend treating test automation as one part of a multifaceted pursuit of an excellent test strategy, rather than an activity that dominates  the process, or stands on it own." That's something I think is even more important today than they day it was written.

Your Code As A Crime Scene

Just finished reading this by Adam Tornhill and wanted to share a quick review of it

Really interesting book. Part theory part hands on experience and as such it's a different style to a lot of programming books which I think keeps you engaged after the enticing introduction which tells you that the same techniques used to track serial killers can help you find problems in your software. It's a premise like that which get's you interested.

Sometimes it feels like a bit of a gimmick. I don't feel like often the forensic techniques are anything more than a touch point that helps you understand the premise of some pretty nifty statistical analysis through your code and particularly your source code history.  We see the map that indicates where jack the ripper may have  lived but then our own code map seems a bit more straightforward. It still acts as a nice narrative and vehicle for getting the concepts across but I don't feel I'm any closer to starting my private detective business unfortunately.

Section 1 starts with the theory to help you understand where the bottlenecks may be in your code and in particular how to tell from how a code evolves and grows how it may have suffered from growing pains. Essentially V1.0 if your code is normally written by a smaller group with a singular purpose but as time goes on more people come in to the project and that can very easily lead to some sprawl of the code base and differing standards and implementation styles so it's great if you can try and identify those areas because they may need a proper ground up redesign.

This is done through a couple of different mechanisms one of which is mining the richness of information in your git history. The tooling provided will allow you to find code which is complex or could be home to many errors another way of doing that which has been suggested by colleagues was just to keep an eye out for anywhere I had made commits....dickheads.

So while you may not be pounding the beat whilst looking for clues as to where the issues are, what you get instead is some great heuristics and insights. A lot of them that I have no experience of like indentation-based complexity for example which indicates you can judge complexity of code visually from how it's indented. All of these techniques are based on academic finding and Adam acts almost as a conduit bringing these to industry to say hey this could be useful to you today don't want for it to become a fancy start-up with a .io address.

We also get to have worked examples both on the code base that's used to analyse code bases (how meta ;) ) to NHibernate and others. It's brilliant to get this level of hands on work in a book which could easily disappear into theory and intellectual grandstanding. It makes the examples feel like something you can actually aspire to and all in all this made me interested in checking out Microsoft R (pretty sure there is a free EdX course on it) and checking out the world of data analysis.

Section 2 talks at length about automated testing and also some of the shortcomings you can have with the implementation when you have an 'extensive' set of tests that are too close to the code and counter-intuitively slow down progress you can make.

I found the chapter on this to be probably the most interesting and thought provoking of the book. It's not often a developer will talk about writing tests and even less want to draw attention to the tests they've written but this is a frank discussion about how the best intentions around testing can end up weighing you down because the same discipline and thought processes we bring to the application code isn't present often in the test code.

Section 3 is on social psychology and so its very different to what has come before. It's less actionable (to start but does come back around) and I guess more of intellectual value. That's not to say there isn't touch points of real world but initially it's removed from concious thoughts etc. Interesting points include discussing why Brooks law on increasing team size doesn't fit for open source projects.

This feels like a manual for sitting down and working out how to mine the information rich source that is in your source code history. As an industry which has such a steely focus on big data etc we often seem wary to turn the microscope around to look at ourselves and see what can be learned about how we work and what makes for successful software delivery. Though the techniques may not stay the same I truly believe this book could make a big difference to how software gets delivered. Actionable metrics for software development is such a bloody minefield that it's hard not to be really floored when someone can not only show you actionable and scientifically backed ones but also make it an interesting read.

I'm going to make a concious effort to use the tools listed in the book and see what information we can bring out. We are in a pretty distributed project set-up (which I guess is becoming the norm via micro-services) so sometimes I think some of our temporal dependencies will be lost because it's across multiple git repos but I still think a lot of what is discussed and reasoned about here will be useful. When you have a book like this which isn't about a technology explicitly or about a class of problem I think there's no higher praise than to say it's thought provoking and has driven me to want to implement what's talked about as soon as I can.

Well worth a read!

CodeSchool - Javascript Road Trip

I'm a javascript noob. I have, of course, like most developers changed javascript and written something approximately like Javascript. Like most developers I've done that really badly but with a level of confidence and bluffing that I may have gotten away with it. So when I saw the Javascript track on codeschool.com and in particular the "JavaScript Road Trip" I thought hey maybe this is point that I should sit down and try and learn it. 

Starting out on the Road Trup?

The video, and therefore the first segment of the course, starts with our intrepid teacher walking along some railroad tracks.

I think this is because we're going on a journey but it may also be because he's hunting the most deadly game of all...bindle swinging hobos. He has running shoes on which supports this and a bloodlust in his eyes that is quite hard to escape.

Ok no it was a journey metaphor. For now anyway. We get a lovely little intro with a strong javascript song. I'm fully into this now.

The first part of the road trip is a free course but when this says the basics of Javascript they really mean it. Truth be told most of it is the basics of programming as very little of it feels javascript specific. Some of it is strongly computer science 101 so if you are an experienced developer you may find this slightly hard going to sit through initially. So the free part is probably of limited value to experienced developers but don't let that put you off the overall Javascript course.

So do I need to take a U-Turn?

NO! Definitely not. Yes the first segment does start at a pretty basic level but It does however develop over the rest of the roadtrip (Not free) and it really does move it along at a good pace. These 3 module that make up the roadtrup  are the building blocks for more specialized courses (Angular/Node/Ember/Backbone) later on but they really do help as they touch on functions, closures, protoypes and a lot of the central concepts you need if you want to get into Node etc. 

I've made some further progress along the overall syllabus and can say the best practices course is well worth a look. It talks about performance, ternary operators and other bits.

Is it worth it?

Definitely worth dipping your toe into. Which I think could also be an incredibly strong Tinder bio so feel free to use that if you so desire.

It is short but peppy which is how the police normally describe me in their records.

The presenter kind of walks that line of being cheesy and earnest in a nice way.  It kind of reminds me of Head First style of books a little. It's informal and relaxed but the content is absolutely sound. I think Jason Milhouse (https://twitter.com/ItsThrillhouse) does a really good job all round but I've found it hard recently to shake the feeling that he may be a character played by Michael Ian Black. IN A GOOD WAY.

The best bit here is and I assume it's common across all courses is the ability to do stuff in an interactive console as  worked examples. This is obviously the code school mantra of learning by doing and I think it's really nice.

Btw first time using code school and the interfaces with challenges etc is really nice. I think I might just need to find another topic, I'll be continuing on the JS journey (because of the theme song mainly) as it does stop at cultural hotspots like Angular and Node on the way. Also I am sort of sure there will be some Hard Target style hobo hunting soon.

I think the overall course offered here is a great way to build or improve Javascript knowledge. You finish the roadtrip feeling a lot more comfortable with the whole paradigm and ready to get into the specialized courses that allow you to play with the cool frameworks. 

I know a lot of people have one eye on improving their Javascript knowledge and I think this course as part of the larger syllabus at codeschool is a great way to do that.

I give this course the golden bindle. 

Pluralsight Course - Yeoman Fundamentals

So as one of my New Year Resolutions I set myself the target of taking 12 online courses this year.

The first course I took is quite a short one. It's a good introduction to Yeoman. I found it through an email shot from Plurasight about new courses recently. It wasn't a technology that I was familiar with so it piqued my interest.

What is it?

Yeoman( http://yeoman.io/) is an application that allows you to build project scaffolding templates so you can take the sting out of spinning up new projects. It's installable as a npm package and getting started is quick

Where would I use it?

It is deliberately technology agnostic. Even though it is a Node based application this isn't only for starting new node applications. You can find generators for most technologies. That’s a really nice touch because if you're starting with a new technology it might be useful to leverage some tribal knowledge from the community to get started up in a common configuration.

If you find yourself spending a lot of time just ramping up a project this might be a good tool for you.

This course sets out to guide you on the path to creating your own customer generator. There are a lot of community built generators out there so if you think you would rather just be a client maybe you don't need the course as there's probably enough in the documentation

What's the barrier to entry?

JS knowledge and Node experience isn't NEEDED to follow it but definitely would help. I think though the more you know the easier it's going to be to follow. I did end up deciding to not follow along but instead just watch the screen cast.

Is the course easy to follow?

I found the course very easy to get started on.

Steve Michelotti (https://twitter.com/smichelotti) was a good guide on this. He's very clear with everything he explains. He brings you through static files to using EJS templates. I think by the end of this you feel confident enough at least embarking on creating a generator for real.

I mentioned before that if you aren't planning on building a custom generator then maybe the course is slight overkill. Whilst that's true I personally found it useful to see some of the inner workings and get a little bit deeper with how it works.

The one negative I would say, and it's my own fault, is I'm actually not that au fait with the whole Node ecosystem and I found myself pausing to go WHATS THAT or WHAT a lot. It got the the point I stopped trying to follow along with my own version and just watched what was happening as I felt I really needed to focus. For others with experience of those tools etc I think it will be

Yeoman also offer their own codelab tutorial on building an application with a generator so more using yeoman than building with it. It's expected to take an hour so would be a little shorter and may be a good free alternative

How I may use it in the future :

So initially I thought this is maybe not going to have a practical use for me because I'm not in a front end shop doing lots of new custom websites/projects. Then it dawned on me (and not surprisingly it had already occurred to everyone who ever used Yeoman before) that this fits perfectly in a Microservices environment too.

If you have a preferred structure of projects then creating a yeoman Generator just makes sense. The cost investment isn't huge as there' s a lot of very good starting points already. It's great to get everyone starting off on the right foot.

Would I recommend it?

If you have access to pluralsight then definitely. It's a small course at a good pace so well worth a visit. Failing that the free codelab tutorial looks good for learning how to use yeoman and the wealth of generators currently out there.

Book Review : Intercom on Product Management

Intercom on Product Management

So this is a book I picked from Mathias Meyers 2015 Reading List, which is a fantastic resource for anyone who is wanting to find some inspiration on some books to read. It's a mixture of technical software books and also fiction that he read. This one really stood out to me, interesting topic and a very interesting source. Intercom are a very interesting company with a great product, they have offices in Dublin and a very active blog which is a good read so this definitely grabbed my attention.

Also its FREE, hella free, and that's pretty awesome. It's 60 pages as well so it's not a huge investment of time either so I think it's a great one to pick up. So go do that

I'm not a product manager but in a company who is making the transition to a product company. Whilst I'm not a product manager I feel an attachment to our product and what we offer. I think that's pretty common with a lot of Engineers and most of us will be engaging in conversations with your product manager a lot. You should be. You are immersed in the product a lot of the time so in some ways you could be one of the more prolific users. I think as a software developer this is a very valuable read and really nice to be able to try and transplant your view on software deliver to that of your colleague in a different role. One of the really important pieces about being in a cross-functional team is understanding everyone's goals.

It's an interesting place to be somewhere that's gone from a custom software shop to a product company as a lot of the thoughts and documents (like this one) are from companies that started off as a product company. With that in mind I don't think it's always relevant to the day to day challenges we see but this book does a really good job of trying to lift itself up and talk in general terms about trends and principals which is always the most useful.

I won't go into too much detail. It's a short book but one that is focussed and I think to me there are a couple of big takeaways

Engage with your Customer

This is the number one take away and from a company that has their business based around this concept I don't think that's a surprise but it's one that makes perfect sense.

To me, one of the biggest trends of last year was companies talking about their A/B testing and it's infrastructure. LinkedIn had a number of posts on their blog about it and I think monitoring behaviour and attempting to gain insights is a huge thing at the minute. Intercom certainly don't speak against that practice but also talk about direct customer engagement too.

Find out what people are using. Use that to drive your roadmap. Let the numbers guide you but don't be a slave to them. They had a blog post on that topic as well. I think the biggest thing to me is if you have data it should be shared or available to cross functional team.

Be Ruthless about what's valuable

Couple of quotes that really stuck out for me

There is no pride in having a “big” product with lots of features, only a highly engaged one. The more surface area your product has, the more important it is that you chase engagement and learn from your mistakes

and

If you want a well defined product, you must be comfortable killing features.

The concept of killing features and constantly interrogating the value delivered opens up an avenue of work that's normally removed from the development team. We're closest to the release of a new feature but the care and feeding of those features or more the choice of which to feed is probably not part of our day to day.

Removing features from software sounds so counter-intuitive. We're conditioned to believe that we should always be adding new features but the argument here seems to be not only regarding engagement but also real estate and sprawl. We probably only have so much ground that we can use to be meaningful before the product can become unwieldy and as such we should look at that land and make sure that those features haven't become a diminishing return.

Cutting back features is helpful. Maybe the best metaphor is pruning a plant. It gives us the ability to shape, remove deadwood or increase yield.

Nothing is really free right...

So this is no exception. There's a pretty substantial undertone in the book that if you want to be successful and having engaged users with successful features you need to engage with customers in app. Coincidentally ;) that's what Intercom do for their business...

That said it's not too obtrusive and I think the overall message is pretty sound. I think the fact that they are eating their own dog food in terms of contextual endorsements shows that they really believe it.

Summary

It's free. It's not obscenely long. It's definitely worth a read even just to clarify you on what the end goal of day to day coding really is and that's keeping the customers engaged and happy. Would really love to know what anyone with a product management background thought of it.

I found it challenged a lot of things that I always held dear like "Delivering Software is the most important thing" to instead try and focus on the value that's being delivered. Sounds simple but when you are closer to the execution sometimes you can lose focus on that.

The Software Craftsman - Book Review

The Software Craftsman is the first book I have read this year as part of my resolutions, and truth be told this book is the reason behind those resolutions. That's how much this book resonated with me. Sandro Mancuso's book is practically a call to arms for developers to care about their craft and plan a career around developing knowledge and skill rather than purely titles or salary increments.

Bob Martins introduction compares the book to Roberta Flack song "Killing Me Softly" which is about a singer who sings a song that stops her dead in her tracks because it's like he knows her inner most thoughts. He mentions that this book is that for programmers. I think that speaks volumes. This isn't just a collection of war stories from a grizzled experienced developer but it's the basis of a blueprint for young developers to follow and one that's spawned a movement that is still developing and growing across the world.

The book itself is split into 2 very distinct sections. One on "Attitude and Ideology" and the other on "Full Transformation" which discusses the fallacies in Job Descriptions and Interviews and the challenges of dealing with morale problems. I found myself aghast at the frankness of the author as he talks about the challenges of clock watching developers and other topics that not many people talk about but most of us deal with. Other topics which get touched on are terrible interviews, terrible job descriptions, reluctance to change, intellectual bullying or terrorism by individuals and how to counter it and many more.

It would take too long to go deep into everything this book talks about and achieves so I'll just try and hit the hight points to me and recommend that you take the time to pick it up yourself.

Caring for your work. Pragmatism.

The running theme of this book is about embracing and owning your career. It's about not thinking about the next two years but more where you think you want to develop yourself long-term and looking to realise that through challenging yourself to make progress towards that. It talks about moving jobs to round out experience in different technologies or working environments or to work with different mentors with differing styles.

The book attempts to provide a core set of values or manifesto that are not linked to working processes or technologies. Essentially to me the message is keep an open mind, learn and adapt and never tire of looking for ways to improve your ability.

Always improving yourself or Owning your Career

This talks about the ways to keep your skills sharp but also for taking the responsibility to do that in your own time. I love where I work, we have access to many resources to learn and also the ability for training and taking time out of our working days to learn new things. I cannot stress how lucky I feel to be able to do that. I also know from personal experience and also from interviewing external candidates that it's very easy to get into a very difficult situation were the work is dry and you are not encouraged to really divert your attention from the mechanical execution processes that are expected of you. If you feel like you might be in a similar place to that and want to find a way to get out of it then I honestly think this book has some direction (also check out this really nice blog post from StackExchange). This book has practical advice including book reviews and a way to understand which books are going to add the most value. It references Kata's, a new concept to me, as a way of improving or learning new languages. The overall message is strong though, if this is important to you then make time and get yourself out of your comfort zone.

Culture of Learning and Driving Technical Change

Two of the hardest things to do within an organization. Fostering a culture of learning and bringing other employees along with you is tackled with such gusto that it really does make
you believe it's possible. That's something that's very close to my heart and again the strength of conviction in this book makes you want to re-up your efforts. The important point that's
made is do it for yourself and be open to talk to people about it. You'll find like minded people will be attracted to join in. Trying to enforce adoption isn't going to work. It removes
value from the group if people are there because they have to be. Recently in work as well as us getting the technical blog up and running again there has been a big take up in
brown bag sessions and people wanting to talk at them. I had hoped to start a book club this year but instead I'm going to take the advice of this book and just talk the back legs of anyone
who gets near me about things I've read about or found interesting and encourage them.

Any Negatives?

One thing I have found difficult to ratify with myself is the description or perception of management and managers. Initially on reading the book I felt it was definitely a negative slant on it, now I think with time it seems like it's more a statement that the jobs and career paths are drastically different.
I don't think the intention was to disparage the role of a technical manager, but I'm loath to attempt to speak for the writer at this time. There are very few references to the potentially positive impacts that technical management can bring and most of the 'management' value that is spoken about I think is product management organizing a backlog for the engineers to execute against. I personally believe that some of the things being discussed around enabling growth and building welcoming cultures with a focus on learning can also be driven from a management position, but then I was always
going to say that right :). The book talks a lot about how developers can communicate with management and others to let them know the importance and value of the craftsman process and
techniques but why can technical managers not also be part of that culture and learn too.

We continually talk about the days of command and control traditional management being dead
but don't seem to value the new approaches around coaching, enablement, insulation and advocacy. Sometimes I feel like the worth of that function is under-appreciated and all that is wanted these days is the much fabled 'servitude management' and essentially for managers to just get out of the bloody way. The message and principles of this book are too important to simply reside within the development organization and to me it's similar to a single department 'doing agile' because it will be met with confusion by other stakeholders.

Summary

That said I think this is an important book for any developer especially anyone starting out on the road of their career. Sandro references some texts which he believes to transcend individual technology choices and hit to the very heart of what it is to be an excellent software developer. I think his own book belongs in that group. I really can't stress that enough I think this book is up there with "Clean Code" and others as books which I wish I had read sooner.

Things I've taken from this Book

- It inspired me to pick up the blog and set the resolutions I did
- It's caused me to have a frank self-evaluation of my abilities and my career
- I had no knowledge of software kata's before having only really knowledge of the 'kanban flavour' (This Slide Deck describes it this is an excellent link btw so if you have time well worth a visit)

New Years Resolutions 2016

So I've been shocking at this blog thing.  There's no escaping that but I made a decision last week that this year would be a year of me actually being a real community member as a software engineer. To try and keep me on the right track I decided to basically have some career resolutions but framed up nicely for the calendar year.

This isn't a full new year means new me type deal but rather just taking a few further steps to get out there and broaden my horizons. 

The last time I really engaged with the idea of the blog was when I was feeling pretty isolated working as a Buld Release Engineer and trying to foster a DevOps culture in the office. For a reasonable period of that time I was a singleton role in the office (with lovely colleagues in Boston of course) and I think that really led for me to try and reach out and talk to people. I was also absolutely head over heels in love with Chef (I still am sorry) and couldn't shut up about it. I think it accounts for like 90% of my stack overflow interactions as well.

I decided that hell I'm still pretty passionate about software engineering and a lot of the people and technologies I work with so with that in mind lets get straight into the resolutions

The Resolutions

1) Blog at least 12 times

For someone with none in 3 years this may seem ambitious but I have come to realise that the career move I have made into Engineering management in the past year is of interest to people especially because I know I personally have struggled with many parts of that move and not being that individual technical contributor in the same way.  Also I'm managing a specialist team in an area I have little experience  (UI Development) and there my crutch of having exposure to technologies and challenges isn't there that can be quite scary and exposing like when you forgot your towel and need to dash from the bathroom to get one knowing full well the curtains aren't closed (quick shout out to anyone who has copped such an eyeful whilst walking in Hillsborough park)

I don't think those struggles are uncommon but there's a lot that can be said on the role of a manager whilst wanting to have autonomous empowered teams.

Also as I was part of the effort to found a technology blog at work this year it's a little shabby that I don't really have a personal blog.

2) Read 12 books related to my job

This effort has been partly inspired by a book I'm currently reading called The Software Craftsman by Sandro Mancuso 

I am lucky enough to work somewhere that has a subscription to safari online so access to a lot of titles shouldn't be an issue. 

Some of the books may have a management or soft skills slant as well but the aim is 12 books with some relevance to a career in software development.

I really want to introduce a book club in work this year so I'm hoping to start small and get a few colleagues interested in specific books.

Take 12 online courses

So there are so many excellent resources for free courses that this should be readily doable. 

Mainly I'll be looking to do something I've mo experience in rather than brushing up on anything currently. 

I have experience with a number of the providers including edx  (functional and saas) to pluralsight (not free but luckily my work has some accounts). This will probably be a mix of shorter technology specific courses to some more building block pieces like those from edx. 

I think there's a real embarrassment of riches when it comes to online courses at the minute so I'm going to me a concerted effort to fill my boots this year.

I'm quite weak on front end technologies so that's of particular interest. 

Make 12 contributions to the open source community

The hard one. I use a lot of open source software and yet my contribution back has been poor. I'm not alone on that front and I know there's a lot of people who like me are willing but maybe unsure as to where to start?

That's what I'm going to find the toughest but I'm going to try and use it as an opportunity to help out, support projects I like and also develop some of my own skills as I do it. For example I've written a few pet projects in go but I'm very much a newbie at it so I'm hoping to get to the point of being able to contribute to some go projects this year. It's unlikely that I'll get a chance to use it professionally this year so this seems like a win win scenario.

Hopefully no one that's seen my code is reading this as otherwise they may say the most noble contribution I can make is standing back and making a financial contribution ; )

Take part in 12 community events

So this is meet ups and conferences and tech talks and hackathons and all that goodness. I dabble a bit but not very often. I went to the Lead Dev Conference with a colleague (Blog post he wrote about it here) and was part of a resilience tech talk last year in Belfast. I keep circling local events and then making excuses not to go and that's pretty short sighted as normally when I do go I really enjoy hearing other people's war stories of using certain tools or facing certain issues.

Software can be quite an isolating place to work until you realise that there is a whole community of people who get excited about the same things.

Getting Started 

So if anyone has any suggestions on any of the above sections or would like to get involved too let me know. You can also catch me on Twitter on @DundrumMuscles 

I should also make a resolution to have a prettier blog as well