Wednesday, 18 January 2017

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.

Example

A 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 Example

On the other hand some of the worst developers I've worked with are the opposite of the past example.

  • They won't admit they don't know the answer.
  • They won't ask for help.
  • They won't treat others as equals.
  • They won't admit they were wrong.

Lessons

Software languages, tools and techniques rapidly change. You can't know everything. You can be the expert of one topic one day, and the beginner in another area the next day. Embrace this and learn as you go. Just be humble about it.

  • Admit it when you don't know the answer. Find out if you can.
  • Ask for help.
  • Treat everyone equally, as you would like to be treated yourself.
  • Admit it when you are wrong.

Wednesday, 11 January 2017

Convention Based Tests

Most projects have some form of convention. Examples would include:

  • Attributes/Properties for REST API's
  • Inheritance for third party base types
  • Assemblies/Packages for third party code that is loaded dynamically
  • Folder or namespace conventions
  • And many other forms of conventions

In 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, these tests are focused on implementation.

Reflection

Tests generally should favour readability and clarity over the removal of duplication. Additionally the use of programming constructs such as loops or conditionals within tests are usually a bad idea. Using reflection is not recommended in most cases though the opposite is true for CBT.

Reflection allows the previous examples to have tests written in a fairly flexible and dynamic manner. Future changes would automatically be tested.

  • Tests to ensure particular types within a namespace have the correct attribute/property applied.
  • Tests to ensure particular types within a namespace have the correct base class.
  • Tests that assemblies/packages required at runtime are present within the bin directory.
  • Tests that folders/namespaces match a team/project naming standard.
  • And so on.

Simpler Tests

In some cases reflection is not a suitable tool for convention based tools. In this scenarios a simpler style of test is required. These are essentially convention based tests that ensure additional tests are written. These simple tests act more as a prompt to the developer reminding them to add a test for a particular convention.

This test would first detect how many types exist within the namespace and then detect how many tests have been written for those types. While this style of test does nothing other than really count the number of expected conventions versus the number of tests, the failure of this test provides a hint to the developer that they have forgotten something.

The key with these simple detection tests is to provide a good failure message that includes details on why the test failed, and more importantly why and how a new test should be added.

These simple CBT work when the use of reflection is difficult. While they may seem primitive, they do provide value as simple reminders to add future tests. Despite this it's worth remembering they provide no guarantee of the quality of the additional tests that are written. Here peer review is required.

Lessons

  • Add convention based tests if a convention cannot be detected by static analysis or you cannot detect issues with higher level tests.
  • Reflection is a valid tool to write a single CBT that covers many areas.
  • If a CBT is hard to write, use a test to prompt you to add further tests in the future.

Wednesday, 4 January 2017

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 Liabilities

At 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 (things that give you income) and reduce or eliminate liabilities (things that take your money away) as much as possible.

Investing

Despite knowing nothing than the basics of the stock market and investing, investing in stock (sometimes known as equities) is one of the ways to maximise assets. Again a few simple introductory books and some online research was all that was required. Having explored individual stocks, we settled on low cost index funds as our main investment solution. Before we could invest though we had to attack our debt. Without eliminating the debt we were unable to maximize our investments. Paying off debt is also considered a guaranteed return, something you cannot get with investments, hence it should be your first target.

Debt

Attacking debt took up the whole of 2016. Thankfully there was an easy system to follow. The difficult part is sticking the course, though you will quickly start to see benefits. The best solution we found is the debt snowball, which is part of Dave Ramsey's Baby Steps. Steps 1-3 must be completed in order, sequentially. While steps 4, 5 and 6 can be completed in parallel.

Baby Steps

  1. Save £1,000 in an emergency fund.
  2. Pay debts down from smallest to largest using the debt snowball method.
  3. Save 3-6 months of living expenses for a fully-funded emergency fund.
  4. Invest 15% of income into retirement.
  5. Start funding higher education for children.
  6. Pay off the mortgage early!
  7. Build wealth and give!

You Need a Budget

I was actually advised to create a stick to a budget by a friend while in university, however I ignored her wise advice. A budget is a crucial tool to paying off debt and in turn staying out of debt. The best budget to use with the baby steps is a zero based budget. In this case you run your personal finances like you would a company such as a bank. At the end of each month (or whenever you receive income) your balance should be fully allocated to equal zero pounds available. All of your money is either paying of debt or working hard in investments, while the rest is allocated to expenses.

A written monthly budget is single handedly the best piece of personal finance I can recommend to others. Once you tell your money where to go, and have a audit trail of where you are spending you have control. How we lived prior to a monthly budget is a mystery, though it does explain the shocking net worth we amassed. To be blunt, get and use a budget. You need to.

Retirement

Previously I thought of retirement as something you do when you're old. Think of your parents or grandparents. However this is not the case. Retirement is simply being able to do what you want to do, whether or not this includes work. Being able to wake up each day and do what you want is a powerful thing.

Another shock discovery was the fact that becoming financially independent in order to retire can be done in ten years, instead of the traditional thirty of forty year window. A whole community exists that prove this is the case - FIRE (Financially Independent - Retire Early). To summarise this process, instead of doing what the norm do and investing 10% of your income, invest 50%-90% and you can shorten the process dramatically. FIRE is a long term goal that requires minimized expenses and a strict budget, but the pay off will be more than worth it.

2017

Our personal goals for 2017 include completing our six month emergency fund, followed by aggressively paying off our mortgage, with the goal to complete this within two and half years versus the remaining twenty year window. Without the basic concepts above this would have not been possible.

Lessons

  • Eliminate all debt, and stay out of debt.
  • Create and use a monthly budget.
  • Use the baby steps to get out of debt and build wealth.
  • Low cost index funds are a recommended way of simple investing.
  • Retirement isn't a thirty or forty year process.
  • No one will teach you personal finance, it's up to yourself to get to grips with it.