DEV Community: Benji Stephenson

Make Expressions, not Statements

Benji Stephenson — Thu, 17 Aug 2023 23:42:49 +0000

I was chatting to a colleague about Haskell the other day and some of the qualities it has, such as everything being an expression and how that can encourage the use of smaller functions.
The drive to use expressions over statements is something that I've advocated for for quite a while at work as I think it has a strong set of benefits over merely making statements. Although not all languages make this a first class citizen, it's still usually possible to do.

TL;DR at the bottom

I'll use a couple of languages, but let's start with Typescript. Say we want to get the age bracket of an individual, based on their age range. We might do something like:

var ageBracket: string

if (age <= 12) ageBracket = "junior"
else if (age >= 19) ageBracket = "teen"
else ageBracket = "adult"

So what's could we say is a problem with that? We could wrap the logic up in a function and avoid the mutability, but I think the aspect that we're still dealing with statements remains. A statement is a bit of code that does not return a value and so can't be chained very easily. An expression on the other hand returns some value and can easily be built into a larger expression to achieve something more complex.
Scala is a more expression based language and so allows us to do things like:

val ageBracket = if (age <= 12) "junior"
  else if (age >= 19) "teen"
  else "adult"

One mode of thought is that statements describe how to do things, expressions state what to do. Here's another example:

const nums = [1, 1, 2, 3, 5, 8, 13]
var total = 0
for (var i = 0; i < nums.length; i++)
  total = total + nums[i]

It's quite low level in that is describing how to loop through an array of elements and then compute a running total. The for statement also does not return anything, if we wanted to do something afterwards, we must do so with a new statement. Compare with:

[1, 1, 2, 3, 5, 8, 13].reduce((total, n) => total + n, 0)

In Scala we get something ever more pleasant:

List(1, 1, 2, 3, 4, 5, 8, 13).sum

List(1, 1, 2, 3, 4, 5, 8, 13).fold(0)(_ + _)

Great, so what? Let's add a couple more example steps, again in Typescript, well filter for even numbers, double them and then get the word for the number (2 => "two"):

const nums = [1, 1, 2, 3, 5, 8, 13, ...]
var odds = []
for (var i = 0; i < nums.length; i++)
  if (nums[i] % 2 === 0) odds.push(num[i])

var doubles = []
for (var i = 0; i < odds.length; i++)
  doubles.push(odds[i] * 2)

var names = []
for (var i = 0; i < doubles.length; i++)
  names.push(getNumberWord(doubles[i]))

We end up with quite a lot of intermediary variables. If we change the functionality we need to keep track of whether we should get rid of them or not, IDEs help with this of course, but it can still be pretty easy to end up with unused code lying around. Compare with:

[1, 1, 2, 3, 5, 8, 13, ...]
   .filter(n => n % 2 === 0)
   .map(n => n * 2)
   .map(getNumberWord)

I find it to be much more descriptive and declarative, we talk about what it is we want the code to do and don't have to be concerned with the how.

Related to the intermediary variables point, expressions also allow us to more tightly group related bits of functionality or logic together. To go back to the sum example:

var total = 0
for (var i = 0; i < nums.length; i++)
  total = total + nums[i]

Here the initial value for total and indeed the logic to do the addition is free to be moved around, away from the loop implementation. Not implicitly a bad thing but it does make code harder to reason about when it's spread apart. What if we also forgot to initialise total? Depending on the language, we could get an exception or we could get behaviour we didn't expect. Javascript isn't as well behaved, but in the Scala version

List(1, 1, 2, 3, 4, 5, 8, 13).sum
List(1, 1, 2, 3, 4, 5, 8, 13).fold(0)(_ + _)

it's impossible to forget the initial 0 value for the fold as the compiler would yell at us and in the sum version it's implicit.

Obviously these are really contrived examples but generally I think they illustrate the point. When we have statement orientated code we usually end up with less of a set of , declarative building blocks and more of a longer set of lower level instructions that are much harder to compose.

There's a great talk by Paul Louth, the writer of the C# functional programming lib language-ext where he talks about statements vs expressions that's well worth a watch., he talks about much more than I'll go into here. I love his examples (around 25:30) of how statements are much more open the insertion of side-effecting changes in a more uncoordinated way, whereas the expression based approach forces you to be more structured and deliberate.

I'm a big fan of FP and FP languages, but lots of the patterns and practices that I think make them great can be applied to other languages too and this is definitely one of them, I hope you give it a try and see how it feels.

Summary

In my experience, expression leaning code makes for a much nicer experience in writing and reading code. I find it helps to create more maintainable and composable solutions to problems.

Statements

describe how to do it
leave the code open to modification
intermediate variables/state
tend towards more mutability
easier to rot

Expressions

return values
describe what to do
keeps related logic/functionality contained and together
leave the code open for extension
composable

Week-note; starting 07 Aug 2023

Benji Stephenson — Sun, 13 Aug 2023 05:38:24 +0000

Historically, I've been pretty consistently inconsistent with practices like these and having missed the last two week notes I'm reminded how difficult it is to form good habits.

It's been a rather busy couple of work weeks though, despite not having an active client to work with. Participating in the flow framework workshop that we ran with a client went really well and I got some great experience in facilitating larger groups, so looking forward to the next one. Also has the pleasure of co-running a SAFe advanced Scrum coach training with a stellar facilitator that I learned a lot from.

The Agile Coaching Lab sessions continue to be great and the timing is exactly what I need as we're covering a lot of facilitation techniques now. I can't wait to put some of it to use in my next client role which I think will take on more of an engineering coaching shape. It's good challenging my idea of what I think my ideal career path looks like, but I'm still pretty sure it would contain some amount of code. A change a perspective is always good though and I got some of that from attending a portfolio management mini-conference so see what technology looks and feels like from a business lens.

I'm keeping it short this week, ease back into it and all that.

Week-note; starting 17 July 2023

Benji Stephenson — Fri, 21 Jul 2023 06:43:20 +0000

Another week, and even more coursework content has gone by. Alongside combing up to the 1/2 way point for the Agile Coaching Lab course I'm also about 1/2 way though the Flow Framework Advisor certification which has been pretty interesting.

ACL-wise, we've been covering the Clean Language practice and more generally the idea of powerful questions; how do we ask and prompt in a way that juices as much info out of our clients as possible while also ensuring they self reflect and feel held. It reminds me of the "are we in solution mode or listening mode" view that I've experienced before. We've got a short workshop to run next week on Concrete Practice which I'm looking forward to co-running,
It's actually been quite nice to have a course on the go alongside the ACL, some of the content we've covered on mentoring skills and teaching techniques have prompted me to think about ways to convey some of the Flow concepts to clients that links to what they already know about their organisation and current practices.

Also combined with existing work commitments has been a real test of my time management skills, which are feeling a bit bruised.
Work-wise I'm shadowing and helping prep for a Flow Framework workshop for a pretty sizeable group of 30 people. I enjoy being challenged to facilitate back things that I've learned and it also keeps me honest in making sure I really understand stuff and have'n't just gamed the course to pass the exam!

Other work bits:

Hacking away at automating some of our annual leave process via a Typescript AWS lambda; yes, node_modules is the heaviest object in the universe.
Nice Friday Zoom drinks session that's prompted me to try writing a little more
Looking forward to our monthly get together next week

Away from work but at the same keyboard:

Like every Vim user in existence, the next config will be the best one; I'm rewriting my Fennel nvim setup and it's taking approx. 400% longer than expected
Back to Tai Chi practice for a new term and a new form
Will I ever be done with visa applications? Who knows; it's currently been "in transit" from NZ to Aus for 3 days, which is amazing given it's a 3 hour flight.
Booked up for Taste Martinborough 🍷

Look after yourselves.

Week note; 10 July 2023

Benji Stephenson — Thu, 13 Jul 2023 02:08:57 +0000

This week has been mostly a blur of training videos, articles and a couple of practice exams. Trying to juggle my time between things has been a challenge in and of itself, never mind the actual work involved. On the go this week has been;

Coaching lab week 2 activities
Flow Framework training classes
Code and deploy the internal leave automation service
Aussie visa paperwork

The coaching lab activities were all based around aspects of the agile coach role, how to orient yourself in a new system/team/org and then opportunities to give each other feedback on some slides pitching the coach role. I generally consider myself a pretty introspective person but a lot of the course activities have been a nudge to to do it more and in finer detail, which surely can only be a good thing! Providing it reveals all roses, I suppose...

I've actually enjoyed working on things that are outside of my usual comfort zone as an engineer/aspiring architect more that I thought I would but the bonus is that they all are related in the general digital profession sense.

Ticking off the achievement list:

Submit Aus visa (so much paperwork.... Wonder if they want to talk to someone about their digital services.)
Complete ACL week 2 homework
Learned that mocha pot coffee is, in fact, the best home brew

And all that with my half finished FFXVI game staring at me from across the room!

It's a long weekend ahead, so hopefully my keyboard time will be low and I'll get out on a nice walk.

Mānawaita a Matariki 👋🏻

10 Things I Learned About Code

Benji Stephenson — Mon, 10 Jul 2023 01:20:15 +0000

Or, more accurately, 10 things I learned about software that I wish I knew when I started. But that's not as catchy and didn't fit on the film poster so you'll have to indulge me and my love for cheesy films.

I've been in the software game for about 12 years by now, maybe a few more years if you count the early teen years of playing with Borland Delphi (which is rather strange now that I think of it) and even slightly longer if you want to count all the time having to write BASIC on my green screen Amstrad when I was an actual bairn. So by all accounts, I'm still rather early in my career and still have a million and one things left to learn and probably even more mistakes to make and pick myself up from. But I'm mid-30s now, my knees hurt and now I need to be in bed by 10 pm so I feel long enough in the tooth to offer some unsolicited advice to the internet.

I've had a varied time in the workplace; from one of the big consultancies to start-ups, government to games, junior to senior (whatever that means). These are ten of the things about working in tech that I've been gifted by people much wiser than me, or found out for myself through my journey that I wish I knew at the start.

1. Software is mostly about people

Machines run our code, but that's mostly beside the point; machines can't get annoyed with us and they certainly don't pay our wages, so it's people that we need to foster good relationships with.
The stereotypical engineer likes basements, coffee, arguing over Emacs vs Vim (that's old people VSCode for those of you under 30) and not talking to other humans. But, other humans are where we get our problem statements from, who we're delivering solutions for, who we craft the code with, etc. Making time in our day to forge and maintain relationships with colleagues and peers gives us a network of support and knowledge. We do our best work in teams, after all.

2. Converse more than you code

Insert overused Einstein quote here.
We're coders, so therefore we like to and are drawn to writing code. I think that one of the differentiators between an ok engineer and a great engineer is how they talk through and define the problem they're trying to solve. Talk to more people about it and you'll get more detail, more perspectives, more possible approaches and you'll cultivate a wider, shared understanding of the problem and solutions. The better you can talk about and define the problem, the easier and quicker it'll be to solve through code (or maybe you'll discover you don't need to write any!).

3. The job's not done just because "it works"

Getting something working is great; writing up a solution to a problem is so satisfying and probably the thing that most of us enjoy the most about the job. But it doesn't all stop there. Earlier on in my career, I missed out on the refactoring opportunities, learning how to tidy up the points where my code integrates with other peoples' or systems, all the different ways to approach testing etc. Even when all your tests pass, there might still be a few tweaks to your design you can make.

4. Life's full of contradictions; most of the time "it works" is good enough

Don't let perfect be the enemy of good; there absolutely comes a point where we should just move on to the next job/feature/story and sometimes it's easier to tell when that is than others. In the past I've spent far too long trying to get things slightly better where it wouldn't make much difference to the value to code was offering, it was only for myself. If there's time spare, this is a nice self indulgence but often we could have moved on to something else.

5. Be bold and break things

One way I learn is by breaking something and then having to fix it again. The sign-in flow, the schema migration, loads of stuff has been borked and deborked over the years. Hopefully, most breakages are caught by tests but those that aren't still teach you something about your test approach or the way code interacts with other code, and really, as long as they're all broken and fixed again in a local/dev environment; who cares? I'm not advocating for being a bit fast and loose with code and deployments, but if we're too scared about breaking things then we might not want to take a chance on a new library or pattern.
I remember getting lambasted in my first job when I did my first dev build and broke it three times in a row; all I learned there was to not offer to do the build again.
I still break builds from time to time, I used to care and now I don't.

6. Reading is good, but doing is better

I'm a serial course taker, blog and dev.to reader. I love reading about new patterns and tools I could use in my day to day. The bit I used to get stuck at was actually trying them out in projects, mostly because I wasn't sure the coding style would be cohesive or if it was really worth adding in another library dependency. But I can't overstate the value from just giving things a go and seeing how they work in your code context.
Try things out, see where the seams are and if it doesn't work out, the best thing about code is that you can rewrite it.

7. To hell with hierarchy

Larger companies tend to put more emphasis on team hierarchy than smaller ones, and a lot of the titles are sort of meaningless or at the very least only give a vague impression of differentiation. Senior engineer here might equate to an intermediate over there, for example. But increasingly, I really believe the titles are less important than having a variety of perspectives and experiences and a richness of knowledge follows from that.
Junior, intermediate, senior - who cares? Simply make friends with people you want to learn from

8. Assert(true).is(true); fake it till you make it

No one knows it all; we're just doing the best with what we know now and filling in the gaps, even the lead engineer who built the whole platform on their own over the long weekend. I'm not entirely convinced that the imposter syndrome a lot of us feel ever completely goes away, so I've certainly always felt like I'm faking it all to some degree but over the years you'll realise that the bits you fake get fewer and the bits you know multiply. So give yourself some space; playing pretend is fun, anyway!

9. Balance complexity with simplicity

I love fancy code, who doesn't like feeling a bit clever when they've written something smart looking? Would I still understand it if I came back a month later? If not, then it probably needs a rewrite, or I'll get annoyed at myself for writing something so incomprehensible. And my peers might not be best pleased either.
But everything is a bit complicated the first time you see it, don't let the desire for simplicity stop you from learning a helpful new abstraction that you might have to then teach others. Code simplicity doesn't mean reducing everything to if statements and for loops just because they're the language primitives.

10. Don't believe the marketecture

There's always going to be a time when you need to use a commercial tool or two and unavoidably you'll have to pick one amongst their competitors. Marketing material is easier to get to than technical documentation, especially for closed-source products. Invariably it will tell you a shiny and wonderful tale of how this particular product will solve all of your woes, is absolutely config free and has frictionless upgrades. Sounds great, but does it all stack up in reality?
Off-the-shelf tools can be great and can be the only practical solution to what you're working on, but do read around first. Community reviews or support boards are a good way to get a feel for the tool and how people end up using it to meet their needs and can offer invaluably candid opinions on things.