Confessions of a coding addict.

The following are some professional goals I have for 2018. I'm hesitant to call them New Years Resolutions because these goals have emerged over the course of 2017 and are not a spur of the moment list that I've come up with on the 1st of January. That and I have never liked the concept of New Years Resolutions they seem flimsy, unplanned and all too often they seem to be forgotten by the end of January. So that said this year I aim to: Blog More: In 2017 I posted 9 blogs, not including this one. So I'd like to get at least 10. I'll give myself bonus points if I can average out at 1 a month.  Speak More: in 2017 I spoke at my first conference, DDD Sydney. I'd ideally like to increase that but at least speak a 1 and give several user group talks. That leads to... Submit More CFPs: Last year I only submitted 1. Without giving it much consideration a minimum of 5 seems like a good minimum for this goal.  Keep Coding: This one is a little less S.M.A.R.T. but I re...

I was recently given a really strong reminder on the importance of posture. We all know it's important, maybe it might cause your back/shoulder/arm/etc to hurt if you don't do it properly but we put off thinking about it because it's too hard or not that important. The following is a short account of how I was reminded,0 over the course of multiple surgeries and time off work that used up all my sick and annual leave with still more time off unpaid, just how important good posture is. My reminder came in the form of a 15 cm subclavian blood clot in the left side of my chest. A combination of bad bone architecture, bad posture, compressing my chest cavity, and a little bad luck limited the blood flow through the subclavian vein (running between the collar bone and the first rib) causing a blood clot. I reported prominent veins in my chest, some swelling in my left arm and some minor soreness under my arm to my GP and she sent me for x-rays and an ultra sound. The ultra s...

There is a line in the most recent Star Wars film, The Last Jedi, from Yoda. The greatest teacher, failure is. This line resonated with me in relation to software development. Recently at work we've been having some discussions about challenging our preconceptions about how we do things. Now consider the line from the movie, sometimes we do things a certain way because we know  that it's the best way to do things and probably we're right. How do we know? Is it just some innate thing that everyone  knows? Or is it because someone told us that this is the way things are? Lets look at some things about software development that we know  to be true. TDD is good and makes more maintainable code. Global variables lead to un-maintainable code. The language that you don't like is bad. The language that you do like is good. Now when did you last time that you challenged these ideas? When was the last time that you were able to, knowing that you would probably fai...

Composing components in React means that following the Open Closed Principle (the O in SOLID) is so easy that it's laughable. By composing, or decomposing, React components together new functionality can be added and functionality can be removed without making any changes to the underlying components. Want to make sure that you dont show a profile page unless someone has been logged in? Wrap your profile page in a RedirectToLoginIfUnauthorised component, that checks for the user and redirects to login if they have not yet logged in. As a bonus when you split and compose your functionality like this you end up with smaller components, that do less. So by following the Open Closed Principle in this way you get the Single Responsibility Principle for free. Clean Code keeps on delivering.

In a previous job I had a quote stuck up behind my desk that I would point to when a manager asked me for an estimate.  I cant remember the exact wording but the gist of it was something like: Before asking for an estimate first ask yourself what decisions the estimate will be informing.  I loved this quote because it points at one of the biggest problems that I think the software development industry has with estimates, and one of the reasons that they are, so often, so wrong. Too often we estimate work in a vacuum without adequate knowledge as to why the estimate is being asked for, or how it's going to be used.  There are many different, and valid reasons to estimate work, and different situations call for different techniques. For some of these cases the trivariate estimate method that I suggested in  a previous blog  is a great answer that will provide low level detail about the estimate and allow good decisions to be made, for other cases it is a...

Tell me if this story sounds familiar. You sit in yet another meeting. Listen to business stakeholders talk about what they want. Then you're straight into another meeting where you sit down to come up with an estimate. Eventually you emerge and present it to the business stakeholders. They take this number as fact, as a concrete answer for how long this piece of work will take. Of course in the end the number is not representative of reality. Someone gets upset, because you’ve gone over budget, missed a deadline or simply because reality didn't match with the image in their head. Postmortems are done. The next project starts and the cycle repeats. Eventually people start padding estimates. The whole process breeds distrust, distrust kills teams. Familiar? I thought so. What can we do about it? As an industry we’ve tried a few things. Solutions such as estimating in comparative complexity units like story points hasn't solved this problem, nor has only having experie...

I gave my first conference talk over the weekend at DDD Sydney . I co-presented with my colleague Anjali Wadhwa one of the QAs at nib. It was a great experience, made all the better by the fact that the talk was well attended and received, based on post talk questions and twitter reactions. Moving from giving talks at the Newcastle Coders Group to even a small conference forced me to change the way I think about and practice a talk. At the suggestion of Anjali we broke the talk down into small chunks that could be timed and practised independently. This made practising the talk much easier and allowed us to have time based running notes for the talk. Which meant that we could adjust the talk dynamically if we spoke too fast or got held up on a section. The fact that breaking a talk up into smaller atomic chunks sounds very much like what we do with code was not lost on me. The software craftsmanship principle of keeping everything small and focused on doing one thing well keeps c...

I recently registered a domain for a joke website  saladsimulator.com .  I figured I could whip up the page in a couple of minutes and throw it up on AWS using S3 static site hosting.  All done in an hour or so. What I thought would take an hour ended up in a multi-day ordeal while I tried to get the DNS to resolve.  I went through what seem to be the typical problems. The bucket wasn't configured to be accessible as a website. My bucket wasn't named the same as the website; the bucket needed to be saladsimulator.com to match the domain saladsimulator.com . I got these fixed up and found that it still wasn't working.  I added extra routes in to see if I could Alias or CNAME to a known working site, but they didn't work either. So it seemed it was a problem with something to do with the DNS configuration. After searching around I found a mention in a thread that the name server records in the hosted zone needed to match those in the domain name registrat...

tldr; If you’re getting  curl: (52) Empty reply from server  check that you’ve configured Kestrel correctly. Long version I’ve started playing with Dotnet Core and Docker and have had a few issues getting started. I’ve had a little bit of experience with Docker, though only a little. I’ve worked with DotNet previously but never with Core. Environment The setup I’m using is a Windows laptop running Vagrant. Via Vagrant I’m running an Ubuntu Virtual Machine with the Docker run time installed. Feels a litle like inception. Key Problem The key problem that I’ve had getting started was having my Docker container not responding correctly to my curl commands. I get this: curl: (56) Recv failure: Connection reset by peer curl: (52) Empty reply from server Given that I’m not all that familliar with Docker or Dotnet Core I decided to remove one of the variables and set up a simple Express app in a different docker container. This validated that the commmand I was usin...

Would you work somewhere that advertised. "Working on a well documented code base,  a well thought out product strategy for long term stable well specified contracts all the while using the latest tools and processes to deliver great software?" If you answered yes then you've answered yes to somewhere that may well not follow the agile manifesto. All these things are on the right hand side of the manifesto. Individuals and interactions  over  processes and tools Working software  over  comprehensive documentation Customer collaboration  over  contract negotiation Responding to change  over  following a plan So why point this out? it's because too often I find people forgetting that the agile manifesto and agile software development is about the whole thing, "while there is value in the items on the right, we value the items on the left more." In the end agile is about delivering working products that meet the clients needs and t...