Skip to main content

Posts

Be Humble

Some of the best developers I know treat everyone with mutual respect. Not only this they are open about what they do know and what they don't know. In fact they'll often proclaim I don't know and go about finding out how they can answer your question or solve a particular problem.ExampleA past mentor of mine had a wealth of experience in both the domain and software development itself. In contrast I had no domain experience and very limited practical ability. Despite this gap I was treated as they would treat an equal. No matter how stupid or basic my questions.However our roles switched one day when I explained about my background in games programming. My mentor decided to have a go, a topic on which he knew nothing. He was both humble and happy to be led and openly admitted his shortcomings. In the end we were able to build a basic game. Here I answered what I considered basic questions, while he gained experience.Opposite ExampleOn the other hand some of the worst deve…

Convention Based Tests

Most projects have some form of convention. Examples would include:Attributes/Properties for REST API'sInheritance for third party base typesAssemblies/Packages for third party code that is loaded dynamicallyFolder or namespace conventionsAnd many other forms of conventionsIn a few of these examples static analysis can detect issues, but the majority of these problems would resolve only at runtime.A technique I've used in the past to great success is the concept of convention based tests (CBT). These are tests that ensure a particular convention is followed. As a general practice CBT tend to be written after the discovery of a problem as it is preferable to rely upon higher level tests initially. The good news is that CBT ensure that such problems never return and if a convention is broken you'll be notified during your test run.In terms of quantity there will be a very small number of these tests, and unlike typical tests that focus on behaviour rather than implementation…

Finance For Software Developers

Back at the start of 2016 I set about sorting my personal finances out, inspired by Soft Skills. The book makes a point to consider passive income as a viable solution to wealth building. The reason for this is simple, software developers tend to get paid well if working professionally. Like most professionals though, during school or university you won't be guided on how to handle money until you are thrown into the deep end.Assets and LiabilitiesAt the start of February we listed all our assets versus liabilities and were rather shocked. Our net worth (assets minus liabilities) was negative. Not only was it negative, it was negative by a rather large number. This scary realisation forced us down the path of personal finance. Most of this knowledge came from a handful of books and took no more than a few months to really get to grips with the basics. For the small cost of a few books and your time the return on this investment is huge. In summary you want to maximize assets (thin…

DDD - Events

The act of something happening is one of the most crucial aspects of implementing Domain Driven Design (DDD). I missed the importance of domain events when first exploring DDD.WhyMost requirements come in the form when something happens, do this. Something in this case would be an action, and this would be the result taken afterwards. Most domain events can be discovered when requirements use this sort of language.Another important consideration is that most requirements are evolutionary. They are often added as the feature is developed. What may start off as a single piece of behaviour, may evolve into something much more complex. Events allow this evolution in a decoupled manner.ExampleWhen a blog post is published, update the authors statistics. In code this may have a signature similar to:The publish method is responsible for the publishing of the post. This entity holds responsibility for the pre-conditions and post conditions of such action. Also the method takes a domain servic…

POODR Highlights Part 2

Two other stand out topics from POODR were the use of tests and inheritance. The first set of higlights covered dependencies and arguments.TestsA conclusion that I agree with is that in general most programmers write too many tests.. A great quote in the book sees tests (as) the canary in the coal mine; when the design is bad, testing is hard. Sadly too many poor tests are often written. Examples such as property or construction tests, framework tests or tests that are coupled to the implementation are all common problems. Instead we should aim to get better and more value out of our tests by writing fewer of them, but of higher quality. In short test everything once and only in the proper place. A first step is to simply focus on the ROI that tests give, and focus on the high risk areas.The test categories are broken down into two core types of tests.Incoming Public Messages (public API)Outgoing Public Messages (To public API of another object)State based tests should be used for inc…

POODR Highlights Part 1

Practical Object-Oriented Design in Ruby or POODR is clearly a book about Ruby development, however the odd aspect is much of the concepts apply to other languages. In fact I've taken these ideas and used them both before and after reading the book in other dynamic languages and even static languages such as C#. In summary the book is well worth a read, even if you don't do Ruby development full-time.A few of the highlights for me will be spread out across the following posts.DependenciesThe author takes a firm stance on dependencies. Anything that cannot be controlled by the class itself should be protected from change. In other words a message sent to self/this is preferred than directly interacting with a dependency.I've followed this pattern in the past, but the seeing the justifications for the benefit of this has made me realise the importance of such a practice. In the first example the publish method directly knows about the twitter feed it must interact with. In t…

The New Guy

Everyone is new at some point. No matter your experience level. You're either new to the team or new to the business. Being the new person is both a blessing and a curse.You're NewWhen you're new you come with no baggage. You're full of questions and curiosity.Why do we do it this way?Isn't there a better way of doing this?Have you considered this instead?These are all great questions for new starters to ask, and for teams to hear.You Have a New Team MemberWhen you have a new team member you gain someone with a fresh perspective. They're full of questions and curiosity. Rather than history, they'll be open to new and fresh challenges. A new member can ask you to question current practices. It is very easy to overlook problem areas only until someone with a fresh outlook arrives.How to be NewThere are two roles a new team member must play.LearningChallengingThe learning phase should involve questions, shadowing and pairing. The goal is to learn about the sys…