Category: Kev’s Blog

Posted on

As an industry we still don’t know how to effectively transfer ‘experience’ to new developers

New developers start their careers with a limited grasp of the ‘what’, the basics of how to write code in a given language and tech stack, but the deeper understanding of the ‘why’ and how to evaluate potential solutions and pick the most effective solution given known constraints comes much later with experience.

Experienced developers have knowledge of what they’ve seen work and not work from past development projects and can use this knowledge to make educated decisions. Given any problem, having seen multiple solutions applied on past projects allows you to draw from that knowledge of seeing what has worked and not worked and evaluate what solution is the better option when you see this problem again (or something similar).

Experience and knowledge is hard to pass on from one developer to the next. Programming techniques like iteration and conditional statements can be taught and easily learned, but an appreciation of why solution A is more effective than B is harder to convey, usually because the reasons why one solution is better depends on the context and an understanding of the current constraints that you need to work with. Being able to identify what’s important and what is not is a skill that more experienced developers develop over time, but it’s hard to teach.

Experienced developers add obvious value to any project or team, they provide leadership and the benefit of being able to make informed decisions based on their prior experience that lead to better outcomes for the business with a higher degree of certainty (compared to randomly picking a possible solution without knowing if it’s feasible or the most effective option or not).

The problem we have as an industry is that we still haven’t worked out an effective approach for conveying this experience to other new developers. You can gain experience by putting in the time and effort by working on a variety of different software development projects, but there doesn’t appear to be any easy fasttrack approach to package this information and hand to another developer. Can software development experience be ‘knowledge transferred’ to another developer? Maybe not. Maybe you just have to invest the time to gain experience the hard way.

Misunderstanding or under valuing the experience that an experienced developer brings to a team is a common mistake of someone who does not fully appreciate the complexity of software development. All developers are not equal, and one developer cannot be equally exchanged for another. If we can find an effective approach to easily fastrack the passing of experience from one developer to another, this would massively accelerate the growth of new developers, but maybe the reality is experience just has to be gained the hard way.

Posted on

Updating Personal Access Tokens used with Github Actions

A while back I set up a Github Action to build and deploy an app on each code commit. Since it’s good practice to set an expiry date on your Personal Access Tokens, at some point they will expire and you’ll need to update them.

In my project I reference the Access Token using a Github Secret stored in the settings for the project:

To update the expired or about to expire token:

  • create a new Personal Access Token in your account settings
  • copy the new token value, update the Secrets in your project and paste the new value

Done!

Posted on

New developers: “How do I know what to learn and when I’ve learned ‘enough’ ?”

A question frequently asked by new developers is what to learn, how much to learn, and how do you know when you’ve learned enough?

Learn what you need to solve the current problem and then repeat for the next problem.

Don’t think about his as a finite set of knowledge that you need to learn and then that’s it, that’s the end. That’s not how it works. There’s always something new to learn, and there’s always something you’ll find that you don’t know.

Adjust your mindset to keep this in mind and you’ll be ok.

Posted on

My last 4 phones over the past 13 years (all still work)

For some reason I though I’d sold some of my last phones on ebay, but after clearing out some shelves and cupboards in our house, I’ve found my last 3 phones before my current phone, and they all still work fine. It’s interesting how large current phones are now compared to phones from over 10 years ago – we definitely had a period of phones getting smaller, and now we’re carrying around tablets in our pockets.

Here’s the oldest to last phone I replaced:

From left to right:

  • T-Mobile myTouch4g – this is from roughly 2010. I had it for a few years then reached that stage when it started to slow down so installed a custom Android ROM, Lineage. This always seems to be my sign where I need to upgrade, when I start messing with custom ROMs. Pretty sure I used this phone for at least 3 years. Given it’s small size, it’s noticeably heavy in the hand, maybe because of the solid metal back plate.
  • Samsung S3 – used this phone for 5 years, and only upgraded because the battery started to only just last for a whole day before needing a recharge. Still, 5 years for continual daily use is pretty good innings. I would have used it for longer if it wasn’t for the battery life decreasing
  • Samsung S8+ – probably my favorite phone so far. Even though I recently upgraded to an S21 ultra, I used this phone at home as a music player while working from home (before most recently getting replaced by an iPad)

As a comparison in size to my current S21 Ultra, here’s the myTouch and S3 to the left, S21 Ultra on the right:

It’s interesting seeing the increase in size. My S21 feels completely normal at this point, but the myTouch4g is small enough to fit within my hand.

Proudly powered by WordPress