I’m a lucky developer.

Not because I tend to be able to escape from dangerous situations mostly intact (though that does seem to be a running theme) but because I have the good fortune to work for a company that actually supports the professional development of its employees.

I don’t mean the typical line of “yeah we support you, we totally have a training budget, but good luck getting even a token amount of money to buy Pluralsight to watch courses on your own time” that you usually get. I mean the good sort of support.

The only sort of support that matters.

Time.

Time Is Decidedly Not On My Side

When it comes to extending my technical capabilities, the last thing that I’m worried about is spending money. There are a endless ways to improve yourself in your chosen field without spending a cent thanks to the wonders of the internet, and even if I did have to part with some cash in order to get better at what I do, I would be crazy not to. Every skill I gain, every piece of experience I gather, improves my ability to solve problems and makes me a more valuable asset to whichever company I choose to associate with. More often than not, that means more money, so every cent expended in the pursuit of improvement is essentially an investment in my (and my families) future.

So money is not really an issue.

Time on the other hand is definitely an issue.

My day job takes up around a third of the average day, including some travelling. Combine that with some additional work that I do for a different company plus the requirement to sleep, eat and exercise (to stay healthy) and my weekdays are pretty much spoken for. Weekends are taken up by a mixture of gardening (which I tell myself is a form of relaxation, but is really just another way to indulge my desire to solve problems), spending time with my family and actual downtime to prevent me from going insane and murdering everyone in a whirlwind of viscera.

That doesn’t leave a lot of time left to dedicate to self-improvement, at least not within sacrificing something else (which, lets be honest, is probably going to be sleep).

I try to do what I can when I can, like reading blog posts and books, watching courses and writing posts like this (especially while travelling on the train to and from work), but it’s becoming less and less likely that I can grab a dedicated chink of time to really dig into something new with the aim of understanding how and why it works, to know how best to apply it to any problems that it might fit.

Having a dedicated piece of time gifted to me is therefore a massive boon.

Keeping Employees Through Mutually Beneficial Arrangements

We have a pretty simple agreement where I work.

Friday afternoon is for professional development. Not quite the legendary 20% time allegedly offered by Google, but its a massive improvement over most other places that I know of.

Our professional development is structured, in the sense that we talk amongst ourselves and set goals and deadlines, but it doesn’t generally involve anyone outside the team. No-one approves what we work on, though they do appreciate being informed, which we do in a number of different ways (one-on-one management catchups, internally visible wiki, etc). There is financial support as well (reimbursement for courses or subscriptions and whatnot), which is nice, but not super critical for reasons I’ve already outlined above.

So far we’ve aimed for a variety of things, from formal certifications (AWS Certifications are pretty popular right now) through to prototypes of potential new products and tools all the way to just using that time to fix something that’s been bugging you for ages. Not all “projects” end in something useful, but it’s really about the journey rather than the destination, because even an incomplete tool built using a new technology has educational value.

As a general rule, as long as you’re extending yourself, and you’ve set a measurable goal of some sort, you’re basically good to go.

Conclusion

Making time for professional development can be hard, even if you recognise that it is one of the most value rich activities that you could engage in.

It can be very useful to find a company (or cajole your current organisation) into supporting you in this respect, especially by providing some dedicated time to engage in educational activities. I recommend against using any time provided in this way to just watch videos or read blogs/books, and to instead use it to construct something outside of your usual purview. That’s probably just the way I learn though, so take that advice with a grain of salt.

Giving up time that could be used to accomplish business priorities can be a hard sell for some companies, but as far as I can see, its a win-win situation. Anecdotally, Friday afternoons are one of the least productive times anyway, so why not trade that time in for an activity that both makes your employees better at what they do and generates large amounts of goodwill.

Given some time, they might even come up with something amazing.

I like to think that I consistently seek feedback from my colleagues, but the truth is that I’m more likely to focus on technical work. This is probably because I’m more inclined to work on solving an already acknowledged problem rather than try to find some new problems to work on, which is commonly the outcome of seeding feedback from your peers. It doesn’t help that it requires a specific mindset to really get good value from a peer review.

That’s why this time of year, when my organisation schedules its performance reviews, is good for me. Part of our review process is to gather feedback from a subset of our peers, so I get poked to do what I should be doing anyway, encouraging me to put down the tools for a little while and improve myself professionally with the help of the people around me.

When it comes to peer reviews, personally, I want brutal, unadulterated honesty. If I’ve gone out of my way to seek someone out to get a sense of how they feel about me professionally (or personally, as the two often overlap quite a lot), the last thing I want is for them to hide that because they are afraid of hurting my feelings or some similar sentiment. You really do need to have a good handle on your own emotions and ego before you embark on an a review with this in mind though.

In order to actually engage with people, you want to make sure that you’ve given them something to rally around and get the conversation started. In my case, I try to treat the peer review situation a lot like I would treat a retrospective for an agile team, with two relatively simply questions:

• What should I keep doing from your point of view?
• What should I stop doing from your point of view?

When targeted at personal and professional interactions with a colleague, these questions can lead to quite a lot of discussion and result in opportunities for improvement and growth.

Nuance

I’m a pretty blunt sort of person, as you might be able to tell from reading any of my previous posts.

For me, I want to get right at any issues that might need to be dealt with as soon as possible, taking emotion and ego out of the equation.

Not everyone is like that, and that sort of confrontational attitude can make people uncomfortable, which is the last thing you want on the table when seeking feedback. The truth of the matter is that each person is very different, and it is as much the responsibility of the person being reviewed to encourage conversation and discussion as it is the reviewer. You have to tailor your responses and comments to whoever you are interacting with, making sure not to accidentally (or on purpose) get them to close off and shut down. Nothing good will come out of that situation.

It might seem like a lot of work, when all you really want is some simple, straightforward feedback, but making sure that everyone is comfortable and open with their thoughts will get a much better result than trying to force your way through a conversation to get at the bits you deem most useful.

Hierarchy

Personally, I’m not the sort of person that puts a lot of stock in a strictly hierarchical view (organisation charts in particular bug me), mostly because I don’t like that archaic way of thinking. Bob reports to Mary reports to Jon reports to Susan just feels like a very out-dated way of thinking, where I prefer a much more collaborative approach where people rally around goals or projects rather than roles and titles. That’s not to say that you can escape from there being some people who have the responsibility (and power) to mandate a decision if the situation requires it, but this should be the exception rather than the norm.

How does this relate to peer reviews?

Well, not everyone thinks like that. Some people are quite fond of the hierarchical model for whatever reason and that can bring a whole host of issues to the process of getting honest feedback. These people are not wrong, they just have a different preference, and you need to be aware of those factors in order to ensure that you get the most out of the review process.

If someone considers themselves above you for example, you can probably count on getting somewhat honest feedback from them, because they feel like they can speak freely with no real fear of repercussion. Depending on the sort of person this can be both good and bad. If you’re really unlucky, you’ll have to engage with a psychopath who is looking to “win” the conversation and use it as some sort of powerplay. If you’re lucky, you’ll just get a good, unfiltered sense of how that person views you and your professional conduct.

The more difficult situation is when someone considers themselves to be below you, which can evoke in them a sense of fear around speaking their mind. This is a bad situation to be in, because it can be very hard to get that person to open up to you, regardless of how many times you make promises that this is a purely informal chat and that you’re interested in improving yourself, not punishing them for telling you how they feel. Again this is one of those situations where if you’ve established a positive and judgement-free relationship, you’ll probably be fine, but if the person has some deep seated issues around a hierarchical structure and your position in it, you’re going to have a bad time.

If you do identify a situation where a peer is afraid of speaking their mind due to perceived positional differences during a peer review, its probably too late. Pick someone else to get feedback from this time, and work on establishing a better relationship with that person so that you can get their feedback next time.

The Flip Side

Up to this point I’ve mostly just talked about how to get feedback from other people to improve yourself, which is only half of the story.

In order to be fair, you need to be able to be the reviewer as well, offering constructive feedback to those who request it, and, if necessary, encouraging people to seek feedback for personal growth as well. This sort of concept isn’t limited to just those in “managerial” positions either, as every team member should be working towards an environment where all members of the team are constantly looking to improve themselves via peer review.

Giving feedback requires a somewhat different set of skills to seeking it, but both have a lot of common elements (which I’ve gone through above). Really, its all about understanding the emotional and intellectual needs of the other person involved, and tailoring the communications based on that. In regards to specific feedback elements, you want to be honest, but you also want to provide a mixture of specifically addressable points alongside more general observations.

Remember, someone seeking feedback has already decided to grow as a person, so you’re just helping them zero in on the parts that are most interesting from your point of view. They are likely seeking the same thing from multiple people, so they might not even change the things you talk about, but its still a good opportunity to help them understand your point of view.

Conclusion

Seeking and giving feedback require an entirely different set of skills to solving problems with software. Both sides of the coin can very quickly end in an emotional place, even if its not intended.

From a reviewee point of view you need to be able to put ego and emotional aside and listen to what the other person has to say, while also encouraging them to say it.

From the reviewer point of view, you need to be able to speak your mind, but not alienate the person seeking feedback.

Its a delicate balancing act, but one that can generate a wealth of dividends in your professional life.

If you’re lucky, it might even make you a better person.

Well, for me anyway, because the conferences I tend to go to happen around this time of year.

I’m off to two opportunities for self-improvement this year, DDD Brisbane and Yow!. Unfortunately (fortunately?) they are scheduled extremely close together (Saturday, Monday, Tuesday), so I’ve got a busy few days full of learning coming up. Still, a little busyness is a small price to pay for knowledge. “Scientia potentia est” after all.

I don’t know any Latin beyond what the internet tells me.

DDD Brisbane I had to pay for out of my own pocket (a mere AUD $30, incredibly affordable for anyone looking to take advantage of the experience of others), but my employer (Onthehouse Group) was nice enough to cover the costs of Yow!, so I didn’t have to take that one on the chin.

Last year I only managed to attend DDD, so it will be nice to head off to Yow! this year to absorb all that delicious knowledge. I’ll probably do a follow up post after the conferences are over (assuming I yet live),  but for now this post will be a quick one highlighting some of the things that I’m looking forward to.

Developers, Developers, Developers

There is some good stuff happening at DDD this year. Personally, I’m looking forward to the following sessions.

Panel: What is Quality Code

This is one of those all-star panels that will probably dump massive amounts of experience in a very short amount of time. Featuring some of the more well known players in the Software Development space (in Brisbane at least), I’m sure it will be both engaging and educational.

Designing an API

Indu Alagarsamy & John Simons talk is topical for me, because we are currently investing in the design and implementation of an API that will expose parts of our flagship software that were previously unavailable to external consumers. I’m interested to see what these two speakers will offer in terms of new information, or lessons learnt.

Back to Basics: Simple, Elegant, Beautiful Code

Listening to Andrew Harcourt give a talk is always both entertaining and enlightening, and I’m sure this talk will be no different. Its always a goal of mine to write simple code, and I considering myself a craftsman when it comes to developing software, so I’m interested in what sort of things Andrew has to say on the matter.

Sweet You’re Agile! No What?

Its always interesting to see what people have to say about Agile, and I wonder what Chris has to add to all the other stuff floating about out there.

Yow

I’ve never actually been to a Yow! conference before, though I have watched quite a lot of the videos that they put up after the fact (you can view all of the previous Yow! videos for free at the Eventer website). It should be a good opportunity for me, even though its a much larger, less personal conference. This year I’m looking forward to the following sessions.

Delivery Mapping: Turning the Lights On

Writing software is all well and good, but if you can’t deliver it in a timely, reliably fashion, what does it really matter? I’m hoping this session will provide some new information on that front.

Pragmatic Microservices: Whether, When and How to Migrate

Whether or not the use a microservice based architecture is something we’re currently struggling with right now, so I’m very interested in seeing real examples from big companies (on both sides of the argument) accompanied by some sort of analysis into the desirability of the approach.

Property Based Testing: Shrinking Risk in Your Code

I’m a big proponent of testing, and while I have heard some things about property based testing, my level of knowledge about it would barely fill a thimble. I’m hoping the the content of this session will enlighten me somewhat.

Agile is Dead (Long Live Agility)

In the same sort of vein as the Agile talk Chris is giving at DDD, I’m curious to hear what one of the original founders of the Agile Manifesto has to say on the subject. Personally, I think not enough people pay attention to Agile values and instead focus on the process, thinking that makes them “agile”.

Designing for Failure: Scaling Uber’s Backend By Breaking Everything

Now this is the kind of talk I can get behind. Using AWS as our primary hosting mechanism has only solidified in my mind the fact that anything can break at any moment, so you might as well be prepared for it. I wonder if this session will feature similar concepts to Netflix and their legendary Chaos Monkey, Gorilla and Kong.

Making Hacking Childs Play

Troy Hunt is pretty legendary in the security field, so I’m sure he has to say will have excellent ramifications for the way I think about security.

DevOps @ Wotif: Making Easy = Right

Looking back I’ve always been interested in making sure that software developers are involved at every step of the software pipeline, and deployment/support is no exception. The relatively new culture around DevOps only reaffirms that sort of attitude, taking operational concerns into the programming space. Hopefully this talk will add more fuel to the fire.

Conclusion

The downside of these sorts of conferences is that you simply can’t see everything. At least with Yow! I will be able to watch the videos later, which I certainly will be doing. There were some particular hard decisions made in my list above, and I don’t want to miss out on anything amazing.

As an aside, it really does feel like there is never an end to learning new things in this field and that can be a combination of exhilarating and exhausting. The problem is, if you stop to take a breather, everything moves so fast that you’re already behind the curve. One day it might settle down, but I can’t imagine that’s going to happen in my lifetime.

I’m still not entirely sure if anyone actually reads this blog, but if you do, and you somehow recognise me at either of the conferences above, come and say hi.

I should have posted about this last week, but I got so involved in talking about automating my functional tests that I forgot all about it, so my apologies, but this post is a little stale. I hope that someone still finds it useful though, even as an opinion piece.

Automating the functional tests isn’t going so well actually, as I’m stuck on actually executing TestExecute in the virtual environment. Its dependent on there being a desktop for it to interact with (no doubt for the purposes of automation, like mouse clicks and send keys and stuff) and I’m executing it remotely from a different machine on a machine that is not guaranteed to have any available interactive user sessions. Its very frustrating.

Developer, Developer, Developer was hosted at QUT on Saturday 6 December, and it was great. This post is primarily to give a shoutout to everyone that I saw speak on the day, as well as some of my thoughts about the content. Its not a detailed breakdown of everything that I learned, just some quick notes.

First up, the conference would not have been possible without the sponsors, which I will mention here because they are awesome. Octopus Deploy, DevExpress and CampaignMonitor were the main sponsors, with additional sponsorship from Readify, SSW, Telerik + more. The whole day only cost attendees $30 each, and considering we had 2 massive lecture theatres and 1 smaller room at QUT for the entire day, food and drinks and then prizes at the end, the sponsors cannot be thanked enough.

Octopussy

The first talk of the day (the keynote) was from Paul Stovell, the Founder of Octopus Deploy.

Paul talked a bit about the origins of Octopus Deploy through to where the company (and its flagship product) are now, and then a little bit about where they are heading.

I found it really interesting listening to Paul speak about his journey evolving Octopus Deploy into something people actually wanted to pay money for. Paul described how Octopus was developed, how the company grew from just him to 5+ people, their first office (where they are now) and a number of difficulties he had along the way as he himself evolved from a developer to a managing director. I’ve been reading Paul’s blog for a while now, so there wasn’t a huge amount of new information, but it was still useful to see how everything fit together and to hear Paul himself talk about it.

I don’t think I will ever develop something that I could turn into a business like that, but its nice to know that it is actually possible.

A big thank you to Paul for his presentation, and to Octopus Deploy for their sponsorship of the event.

Microservices

Mehdi Khalili presented the second talk that I attended, and it was about microservices. Everyone seems to be talking about microservices now (well maybe just the people I talk to), and to be honest, I’d almost certainly fail to describe them within the confines of this blurb, so I’ll just leave a link here to Martin Fowlers great article on them. Its a good read, if a little heavy.

Long story short, its a great idea but its super hard to do it right. Like everything.

Mehdi had some really good lessons to share from implementing the pattern in reality, including things like making sure your services are robust in the face of failure (using patterns like Circuit Breaker) and ensuring that you have a realistic means of tracking requests as they pass through multiple services.

Mehdi is pretty awesome and well prepared, so his slides are available here.

I really should have written this blog post sooner, because I can’t remember a lot of concrete points from Mehdi’s talk, apart from the fact that it was informative while not being ridiculously eye-opening (I had run across the concepts and lessons before either through other talks or blog posts). Still, well worth attending and a big thank you to Mehdi for taking the time to put something together and present it to the community.

Microservices 2, Electric Boogaloo

I like Damian Maclennan, he seems like the kind of guy who isn’t afraid to tell you when you’re shit, but also never hesitates to help out if you need it. I respect that attitude.

Damian followed Mehdi’s talk on microservices, with another talk on microservices. I’ve actually seen Damian (and Andrew Harcourt) talk about microservices before, at the Brisbane Azure User Group in October, so I contemplated not going to this talk (and instead going to see William Tulloch tell me why I shouldn’t say fuck in front of the client). In the end I decided to attend this one, and I was glad that I did.

Damian’s talk provided a good contrast to Mehdi’s, with a greater focus on a personal experience that he had implementing microservices. He talked about a fictional project that he had been a part of for a company called “Pizza Brothers” and did a great walkthrough of the state of the system at the point where he came onto the project to rescue it, and how it changed. He talked and how he (and the rest of the team) slowly migrated everything into a Service Bus/Event based microservice architecture, and how that dealt with the problems of the existing system and why.

He was clear to emphasise that the whole microservices pattern isn’t something that you implement in a weekend, and that if you have a monolithic system, its going to take a long time to change it for the better. Its not an easy knot to unpick and it takes a lot of effort and discipline to do right.

I think I appreciate these sorts of talks (almost like case studies) more than any other sort, as they give the context behind the guidelines and tips. I find that helps me to apply the lessons in the real world.

Another big thank you to Damian for taking the time to do this.

Eventing, Not Just for Services

Daniel Little was the first presentation after lunch. He spoke about decoupling your domain model from the underlying persistence, which is typically a database.

The concepts that Daniel presented were very interesting. He took the event based design sometimes used in microservices, and used that to disconnect the domain model from the underlying database. The usage of events allowed the domain to focus on actual domain logic, and let something else worry about the persistence, without having to deal with duplicate classes or dumbing everything down so that database could understand it.

I think this sort of pattern has a lot of value, as I often struggle with persistence concerns leaking into an implementation and muddying the waters of the domain. I hadn’t actually considered approaching the decoupling problem with this sort of solution, so the talk was very valuable to me.

Kudos to Daniel for his talk.

Cmon Guys, UX Is A Thing You Can Do

This one was a pair presentation from Juan Ojeda and Jim Pelletier from Kiandra IT. Juan is a typical user experience (UX) guy, but Jim is a developer who started doing more UX after working with Juan. Jim’s point of view was a bit different than the normal UX stuff you see, which was nice.

I think developers tend to gloss over the user experience in favour of interesting technical problems, and the attendance at this talk only reinforced that opinion. There weren’t many people present, which was a shame because I think the guys gave some interesting information about making sure that you always keep the end-user in mind whenever you develop software, and presented some great tools for accomplishing that.

User experience seems to be one of those things that developers are happy to relegate to a “UI guy”, which I find to be very un-agile, because it reduces the share responsibility of the team. Sure, there’s going to be people with expertise in the area, but we shouldn’t shy away from problems in that space, as they are just as interesting to solve as the technical ones. Even if they do involve people instead of bits and bytes.

Juan and Jim talked about some approaches to UX, including using actual users in your design (kind of like personas) and measuring the impact and usage of your applications. They briefly touched on some ways to include UX into Agile methodologies and basically just reinforced how I felt about user experience and where it fits in into the software development process.

Thanks to Juan and Jim for presenting.

Security is Terrifying

The second last talk was by far the most eye-opening. OJ Reeves did a great presentation on how we are all doomed because none of our computers are secure.

It made me never want to connect my computer to a network ever again. I might not even turn it on. Its just not safe.

Seriously, this was probably the most entertaining and generally awesome talk of the day. It helps that OJ himself exudes an excitement for this sort of stuff, and his glee at compromising a test laptop (and then the things accessible from that laptop) was a joy to behold.

OJ did a fantastic demo where he used an (at the time unpatched) exploit in Internet Explorer (I can’t remember the version sorry) and Cross Site Scripting (XSS) to gain administrative access over the computer. He hid his intrusion by attaching the code he was executing to the memory and execution space of explorer! I didn’t even know that was possible. He then used his access to do all sorts of things, like take photos with the webcam, copy the clipboard, keylog and more dangerously, pivot his access to other machines on the network of the compromised machine that were not originally accessible from outside of the network (no external surface).

I didn’t take anything away from the talk other than terror and that there exists a tool called Metasploit and Meterpreter which I should probably investigate one day. Security is one of those areas that I don’t most developers spend enough time thinking about, and yet its one with some fairly brutal downsides if you mess it up.

You’re awesome OJ. Please keep terrifying muppets.

So You Want to be a Consultant

Damien McLennan’s second talk for the day was about things that he has learnt while working at Readify as a consultant (of various levels of seniority), before he moved to Octopus Deploy to be the CTO there.

I had actually recently applied and was rejected for a position at Readify *shakes fist*, so it was interesting hearing about the kinds of gigs that he had dealt with, and the lessons he learnt.

To go into a little more detail about my Readify application, I made it to the last step in their interview process (which consists of Coding Test, Technical Interview, Culture Interview and then Interview with the Regional Manager) but they decided not to offer me the position. In the end I think they made the right decision, because I’m not sure if I’m cut out for the world of consulting at this point in my career, but I would have appreciated more feedback on the why, so that I could use it to improve further.

Damian had a number of lessons that he took away from his time consulting, which he presented in his typical humorous fashion. Similar to his talk on microservices earlier in the day, I found that the context around Damian’s lessons learnt was the most valuable part of the talk, although don’t get me wrong, the lessons themselves were great. It turns out that most of the problems you have to deal with as a consultant are not really technical problems (although there are plenty of those) and are instead people issues. An organisation might think they have a technical problem, but its more likely that they have something wrong with their people and the way they interact.

Again this is another case where I wish I had of taken actual notes instead of just enjoying the talk, because then I would be able to say something more meaningful here other than “You should have been there.”

I’ve already thanked Damian above, but I suppose he should get two for doing two talks. Thanks Damian!

Conclusion

DDD is a fantastic community run event that doesn’t try to push any agenda other than “you can be better”, which is awesome. Sure it has sponsors, but they aren’t in your face all the time, and the focus really is on the talks. I’ve done my best to summarise how I felt about the talks that I attended above, but obviously its no substitute for attending them. I’ve linked to the slides or videos where possible, but not a lot is available just yet. SSW was recording a number of the talks I went too, so you might even see my bald head in the audience when they publish them (they haven’t published them yet).

I highly recommend that you attend any and all future DDD’s until the point whereby it collapses under the weight of its own awesomeness into some sort of singularity. At that stage you won’t have a choice any longer, because its educational pull will be so strong.

Might as well accept your fate ahead of time.