Mel Reams

Nerrrrd

Not all problems need to be solved with code

Unrelated image from pexels.com to make this post look nicer in social media shares.
Unrelated image from pexels.com to make this post look nicer in social media shares.

If you’re a programmer and someone asks you to solve a problem, that means the problem needs to be solved by writing code, doesn’t it? That’s what programmers do, right? Not necessarily!

Knowing how to write good code is a huge part of being a good developer, but so is knowing when not to write more code. Take this question from reddit for example. If the problem is that you need an online store, writing one from scratch is the last thing you should consider. Needing to be able to sell stuff online is not a unique problem. It’s not even a slightly unusual problem. The more common the problem you’re trying to solve, the better chance somebody out there has already solved it and will sell you the solution for a reasonable price. In the case of an online store, that’s probably WordPress and one of about a zillion ecommerce plugins, or one of many (so many) ecommerce platforms.

To keep beating on the online store example, let’s talk about why it’s such a bad idea to write one from scratch. First of all, writing a whole store from nothing would take ages. If your goal is to sell things, spending weeks if not months building your store and getting everything working just right would be a huge waste of time. And don’t think you’re done just because the store works – if nothing else, you’re going to need to apply security updates to whatever it runs on, and let’s be honest, there will be bugs and you will need to fix them :) Sadly, the more lines of code you have the more potential bugs you have. The more code you write, the more code you have to maintain.

Another reason you shouldn’t write a store from scratch is if you’re taking people’s money, you have to be absolutely sure that you keep their payment details and personal information safe. Protip: security is hard and if at all possible, you should make it someone else’s problem. If you use a reputable plugin or platform, you can be reasonably sure all the security stuff has been done correctly. Aside from security, there’s also uptime to worry about. If your store goes down, you don’t make any money and you get to freak out about what brought it down and how to bring it back up. Again, if what you want to do is sell things, trying to figure out why your store went down is a terrible use of your time. Also, if you use existing software that thousands of other people have already beaten on, you’re a lot less likely to have surprise downtime.

And don’t forget requests for new features! If you build your own store, it’s going to be pretty basic at first. Sooner or later, you’re going to want fancy stuff like sales, limited time offers, discount codes, etc, etc. Yay, more stuff to worry about finding bugs in! Those aren’t even the really scary examples, either. If you decide you want to internationalize your store with descriptions in the local language and prices in the local currency, you may need to rewrite huge parts of it. And then worry about finding bugs in those parts, because there are so many fiddly little details you can get wrong with internationalization.

Developing your own [fill in the blank] can enormously expensive, too. Sometimes it is worth it to develop exactly the thing you need in-house, but sometimes it’s really not. The great thing about commercial off-the-shelf software is that the vendor can sell it for a tiny fraction of what it cost to build it because they can sell it over and over. Even the very newest junior dev’s time still has a value – is a week of their time still cheaper than buying the solution? Is having precisely the feature you want going to make more money than having that junior dev work on something more directly related to your business?

As developers, our first instinct is to start writing code when we want to get something done. That’s totally normal and you shouldn’t feel bad about it. It took me ages to learn to ask whether we actually need more code to solve a problem or whether there’s a simpler workaround. What I wish more developers were taught in school is that our job is to solve problems, not to write code. Yes, sometimes writing custom code is the best solution to the problem, but sometimes a simple wordpress plugin or a cron job is all you need :)

The dining philosphers

Unrelated image from pexels.com to make this post look nicer in social media shares.
Unrelated image from pexels.com to make this post look nicer in social media shares.

I read this article by Uncle Bob called The Lurn (it’s a companion piece to an earlier article of his called The Churn), where he mentioned a lot of topics that he thinks are more important for developers to learn about than just scrambling to keep up with the latest languages and frameworks (not that you shouldn’t learn a few of those, but you’re going to hit diminishing returns pretty quickly because not that many things are actually a meaningful leap forward and eventually you’re going to start seeing enough patterns that learning yet another slightly different framework just isn’t a good use of your time).

One of the topics he mentioned was the Dining Philosphers problem, which I’d never heard of so I went and looked it up. The problem (quoting wikipedia, of course) is:

Five silent philosophers sit at a round table with bowls of spaghetti. Forks are placed between each pair of adjacent philosophers.

Each philosopher must alternately think and eat. However, a philosopher can only eat spaghetti when they have both left and right forks. Each fork can be held by only one philosopher and so a philosopher can use the fork only if it is not being used by another philosopher. After they finish eating, they need to put down both forks so they become available to others. A philosopher can take the fork on their right or the one on their left as they become available, but cannot start eating before getting both of them.

Eating is not limited by the remaining amounts of spaghetti or stomach space; an infinite supply and an infinite demand are assumed.

The problem is how to design a discipline of behavior (a concurrent algorithm) such that no philosopher will starve; i.e., each can forever continue to alternate between eating and thinking, assuming that no philosopher can know when others may want to eat or think.

Yep, it’s a concurrency problem. Specifically, a deadlock problem. Just because it sounds like it should be simple to get all of our philosphers fed doesn’t mean it actually is. The simplest solution would be that each philosopher picks up the fork on their left and waits for the fork on their right to become available – which never happens because the philosopher to their right has already taken it and is waiting for the philosopher on their right to put down their fork.

Okay, so let’s give the philosophers a time limit. If you grab one fork but don’t get another one within five minutes, you put your fork down and wait five minutes, then try again. No dice :( This is something called a livelock (that link explains it particularly well), where all the philosophers grab one fork, wait five minutes, put their forks down, wait five more minutes, and try to get two forks again. Forever. It’s almost the same thing as a deadlock except that the processes can still try to do things, they just can’t actually accomplish anything.

That only happens if every philosopher has the same wait time, though. What if we assign each philosopher a different wait time? That sort of works, but the philosopher with the longest wait time is likely to get less spaghetti because they try to pick up a fork fewer times, and if they’re particularly unlucky may get no spaghetti at all. We could try random wait times too, but only if we wanted to tear our hair out trying to figure out why one process is super slow one day and fine the next. Random numbers are out to get you – if you generate enough of them, eventually you’re going to get a long streak of [insert least helpful result here] and the people trying to use the feature that never manages to get two forks will hate you.

Another solution is to number all the forks and tell the philosophers that they must pick up the lower numbered fork first when they need one. The philosophers each grab the lower numbered fork until we get to philosopher number five, who needs to take fork one before fork five, but fork one is already taken so they don’t take any forks. That leaves fork five available to philosopher four, who sets down forks four and five when they finish eating, which lets philosopher three take forks three and four, and so on around the table.

That actually works pretty well if you only ever need two forks, but if you take forks three and four, then discover you need fork one as well, you have to set down the forks you already have and start over again from two.

Yet another solution is to introduce a waiter and make the philosophers ask them for permission to take forks. The waiter only gives permission to one philosopher at a time to pick up forks, which is great in terms of preventing deadlock but kinda sucks if one philosopher needs forks two and three, and another one needs forks four and five and they can’t get permission to pick up forks at the same time even though they don’t want the same forks.

If you relax the constraint about philosophers talking to each other, there’s another solution: all the forks are either clean or dirty (and start out dirty), and all the philosophers are numbered. When two philosophers want the same fork, the lower numbered one gets it. Any philosopher can ask for a fork, and the philosopher who has it must hand it over if it’s dirty but keeps it if it’s clean. When a philosopher finishes eating, they clean their forks and set them down. This prevents deadlocks and fixes the problem of philosophers who haven’t eaten never getting a fork, but (there’s always a but) introduces more overhead in the form of making it possible for philosophers to talk to each other and keep track of who has which fork.

Those are by no means all the possible solutions, but the individual solutions – and there are plenty of them – are less important than the general point of the exercise, which is that concurrency is hard :) Specifically, it’s prone to weird edge cases and is hard to think about because there are so many moving parts.

And now we both know what the dining philosophers problem is all about.

Talk of the day: Be Awesome By Being Boring

Because I’m a Katrina Owen fan, I’ve watched a bunch of her talks. Recently I was watching her talk on Therapeutic Refactoring (it’s great and you should watch that one too), saw that it was from Cascadia Ruby Conf, and decided to see what other talks from that conference were recorded anywhere. One that grabbed my eye right away was called Be Awesome By Being Boring by John Hyland.

The gist of his talk is that “boring” (stable, commonly used, not shiny and new) technology is awesome because you can trust it, you can get help when you need it, and you can focus on building something useful instead of fighting with your tools.

Even if you’re a beginner programmer and nowhere near ready to worry about whether your production database is going to crash, it’s still good advice. Well known, commonly used tools are way easier to learn because they’ve been around long enough to have docs written for them and to have the majority of the bugs worked out of them, they’ve been used enough that somebody else has probably run into the same problem and asked about it on stackoverflow already, and because so many people use it, even if your exact question hasn’t been asked already somebody out there can answer it.

For example, take a look at the number of questions tagged Java on stackoverflow versus the number of Kotlin questions. When I wrote this post, Kotlin was closing in on 4k, where Java had 1.1 million. I’ve heard good things about Kotlin and I’m not saying it’s a bad language to learn, just that you’re going to find answers a lot more easily with the language that has over 200 times more presence on stackoverflow. Not that stackoverflow is the be all, end all of programming language popularity, but I think it’s a decent measure of how many people are using a language.

Be awesome by being boring, it’ll make your life easier!

Strategy pattern

Let’s talk about the strategy design pattern today. According to good old wikipedia, the strategy pattern “defines a family of algorithms, encapsulates each algorithm, and makes the algorithms interchangeable within that family.” In other words, if you have an object most of its behaviour stays the same but there’s one piece that changes, you want to be able to change that one piece without messing with the rest of the object.

A concrete example would probably help :) Let’s say you’re working on a videogame with monsters that attack the player and you want your monsters to be more aggressive at night and less aggressive during the day. The rest of the monster code like movement and tracking health points or inventory stays the same, it’s just one part of the behaviour that you want to be able to change on the fly. The strategy pattern would let you swap in different “should I attack the player?” algorithms any time and the monster code wouldn’t have to change, it would just call a method on the strategy object it was given.

So how would you implement the strategy pattern? Pretty much the same way you’d implement the bridge pattern, actually. The bridge pattern is about organizing your code and the strategy pattern is about how it behaves (thank you stackoverflow), but the way you arrange your interfaces and objects that inherit from them is largely the same. One difference is that your context class (the one that uses the strategy for something) doesn’t have to change – you could have only one of those and still want to use the strategy pattern. Comparing the class diagrams for the two patterns helps show how similar they are.

Here’s a class diagram for the strategy pattern:

Diagram taken from wikipedia, by Bocsika - wikimedia, CC0
Diagram taken from wikipedia, by Bocsika – wikimedia, CC0

and here’s one for the bridge pattern to compare it to:

By Trashtoy - My own work, written with text editor., Public Domain
By Trashtoy – My own work, written with text editor., Public Domain

If you imagine there’s another ConcreteImplementor, the bridge pattern looks a lot like the strategy pattern. On it’s own I don’t find the bridge pattern diagram super helpful, but in comparison with the strategy pattern diagram it does help illustrate that there are more things that vary in the bridge pattern than in the strategy pattern.

Given that the patterns are so similar, why do we need both of them? Earlier I mentioned that the bridge pattern is about organizing your code and the strategy pattern is about how it behaves. That might sound like a minor difference, but misunderstandings are a huge, huge problem when you’re developing software. It really does help to make it as clear as you can when you’re talking about how you want to arrange your code and when you’re talking about how you want it to behave.

Simple stuff that will make your new team think you’re amazing

Unrelated image from pexels.com to make this post look nicer in social media shares and because Pallas Cats are the best.
Unrelated image from pexels.com to make this post look nicer in social media shares and because Pallas Cats are the best.

Even if you just graduated, there are some simple things you can do to make your new team think you’re amazing, and they don’t even involve any code. Ironically, a huge amount of the stuff that makes someone a really good programmer has nothing to do with sitting down with an editor and writing code. Being an exceptional programmer is as much about making your team more effective as it is about just writing good code yourself.

A big thing that can help your team get more done is to write absolutely everything down when you set up your development environment for the first time at a new job. Everybody means to do this but hardly anyone actually does. No judgement, my current job is the first one where I’ve done a good job of documenting environment setup and it’s my fourth job since graduating from college. If you can, it’s even better if you can write a simple script to set up stuff like environment variables. In some offices everyone gets to choose their own OS and scripts are only so useful, but even a script that only works for one OS at least gives other people something to work with.

Why is this important? Because you are far from the last developer your company is ever going to hire and the less time the people who come after you spend setting up their environments the more time they can spend learning the codebase and actually making themselves useful. It seems minor, but the hours it takes to set up an environment really add up over multiple hires. It’s also incredibly helpful if you’re allowed to work from home and need to setup your environment again on your personal computer or if you switch OSs or need to do a full reinstall or your computer dies and you need to setup a new one. Seriously, just documenting environment setup will make your team think you’re amazing and make everyone who comes after you more productive.

But if you want to do even more, it’s also awesome if you can document parts of the codebase as you learn them. No matter how much sense that code makes right now, you will forget it, and again, this is super helpful to everyone who comes after you.

If your team doesn’t have a place to store docs, see if you can start one. At my work we use google apps already, so it was really simple to create a google sites wiki that can only be viewed by people from our organization. If you don’t use google apps, pretty much any tech company is going to have a spare box you could spin up a wiki on. Whatever you do, just make sure there’s some sort of security – if you’re not going to put concrete details about your code in your docs, there’s not much point having them – and that you’re not using a free service that’s going to up and disappear out from under you one day. If nothing else, you can always put some text files on a shared drive and call it good :)

While you’re at it, it never hurts to document processes like how to deploy to staging and prod, how to fix common errors, where all of the log files for different services are, where those different services themselves are. Basically any time you have a question you have as a new developer, write the answer down where other people can find it. If you need to know, so will the next dev.

The less time your team spends re-learning code or hunting down a lot file, the more everyone gets done. That’s something you can help with no matter how new you are.

Talk of the day

If you share my obsession with software design (and maybe even if you don’t) you’ll enjoy this talk by Katrina Owen called Overkill. The basic idea of the talk is the use of a simple toy problem as an excuse for focused practice. I really like the idea of going back to basics as a path to mastery, that’s actually why I’ve been on my own back to basics kick on this blog.

If you like that talk, Katrina Owen co-authored an object oriented design book with Sandi Metz (who is also fantastic) called 99 Bottles of OOP. I haven’t read all of it myself yet, but I have watched (well, listened to) a few of Katrina’s and Sandi’s talks and really enjoyed them.

Trick yourself into getting stuff done

Unrelated image from pexels.com to make this post look nicer in social media shares.
Unrelated image from pexels.com to make this post look nicer in social media shares.

You know that feeling when you need to get something done and you just don’t want to? Considering this post was published on a Monday, I bet you do :)

When I don’t feel like doing something, I find it can really help to trick myself. That is, I do a tiny little piece of something that’s related to the thing I need to do but that I can tell myself isn’t the real work. For example, if I’m starting a new feature, I might tell myself I’m not really starting it yet, I’m just poking around in the existing code a little and seeing where I could put it if I actually was starting that feature. Or I might tell myself that I’m not really building that feature, I’m just stubbing out a class and writing a few comments about how I would build if it I were doing that, but I’m totally not, I’m just writing comments, nothing to see here ;)

Minus a certain amount of flailing around trying to figure out the best way to do something, this is basically my process when I’m building stuff:

Don’t do the thing, just poke around in the code a little.
Don’t do the thing, just make notes about what you find.
Don’t do the thing, just write down ways you could do the thing if you were going to (but you’re not).
Don’t do the thing, just stub out a class (if needed) where you would do the thing.
Don’t do the thing, just write some comments where you would do the thing.
Don’t do the thing, just stub out a method.
Don’t do the thing, just pseudocode one method.
Don’t do the thing, just fill in one method.
Don’t do the thing, just write down one thing you’ll need to test.
Don’t do the thing, just pseudocode one test.
Don’t do the thing, just fill in one test.

Honestly, that’s the core of software development. Software design and architecture are certainly important too, but I’m convinced the single most important part of actually building stuff is breaking down problems into manageable little pieces. If we had to think about the entire application all the time, we’d all end up under our desks weeping quietly. Only the ability to ignore the big picture for a while and focus on one tiny piece allows us to actually get anything done.

Of course just because “break the problem down into tiny pieces” sounds simple doesn’t mean it’s easy. It’s really common to get side-tracked trying to figure out how something unrelated works (I have the worst time leaving stuff alone even it’s probably not relevant to what I’m currently doing), or to spend far too much time trying to figure out what the best way to do something is (that one’s so common we have a word for it), and sometimes you just don’t know where to start or the problem has so many moving parts that you feel overwhelmed and quietly freak out a little.

On the upside, learning to break problems into manageable pieces gets easier with practice. For me it’s mostly a matter of reminding myself that I’ve done this plenty of times before and I’ll solve this problem too.

If you’re having trouble getting started, see if you can trick yourself into doing something. Remember you don’t have to solve the whole problem at once, you can start with a tiny piece of it.

How does variable scope work?

a black woman types on a laptop
Photo from create her stock

Scope is where a variable exists can be accessed in your code, and it’s surprisingly complicated.

The short version is that a variable that was declared inside a block only exists inside that block. Great, what’s a block? In Java, it’s anything between a set of curly brackets { }. Blocks can be nested, too. A method inside of a class can see the class’s variables, and a block inside of a method (like an if or a loop) can see the method’s variables. Nesting only works inwards, outer blocks can’t see inside inner blocks. Once a block finishes executing its variables cease to exist, so there’s really nothing for the outer block to see.

Java also makes things more complicated with scope modifiers: classes, methods, and variables can be public, private, or protected. Those modifiers only apply outside of methods, they don’t make sense for variables that are just going to vanish after the method executes. Public means the “thing” (class, method, or field/class variable) can be accessed from outside the class. Private and protected classes are sort of a weird special case, they only make sense if you have a nested class inside another one. Public things can be accessed from outside the class, private things can be accessed only from inside the class, and protected things can only be accessed by subclasses of the class where they were declared.

Just like each time a method is run it gets a fresh copy of all of its variables, each time a class is instantiated it gets a fresh copy of all of its variables too. Unless any of them were declared static, in case you didn’t already have enough to keep track of :) The difference between classes and objects created by instantiating those classes was a hard concept for me when I started programming, don’t feel bad if you’re confused. Classes aren’t things you can interact with, they’re just blueprints for things. Once you create an actual thing by instantiating a class, then you can call methods on it. Unless you made that method or variable static, then you can use it without actually having an instance of the class. Static variables are special, normally every instantiation of the class gets its own variables, but static variables are shared between all instances of the class.

Why would you want to have just one instance of a variable for all instances of a class you’ll ever have? If you have any constants in the class, they should be declared static (also final, which means, surprisingly enough, that you can never change it) to save memory. If the constant is only ever going to have one value, there’s no reason to waste memory by giving every instance of the class its own copy. You might also want to make something static if it’s a shared resource like a logger. You really only need one logger per class, so again you can save memory by sharing one logger instead of giving every instance its own copy.

So that’s all well and good, but why does scope work the way it does? Partially I think it’s for the convenience of the programmer :) How much would it suck if you could never reuse a variable name because all variables were visible anywhere? And how much of a hassle would it be to keep track of which variable you were using versus which one you meant if all of them were visible?

Aside from convenience, there is an actual reason for variable scope to work the way it does. It has to do with the way the computer keeps track of exactly which code is executing at any given time. To over simplify a bit, when a program is executed it gets two chunks of memory, the stack and the heap. The heap is where objects live, and the stack is where the computer keeps track of where it is in the program and what values all the variables have. When method a calls method b, the computer stores the state of method a on the stack, then creates a new state for method b with all of its variables and stores it on the stack too. When method b finishes, the computer keeps its return value (if it returned anything), to update method a’s state with, then it throws away the state for method b. That’s what I was talking about when I said that variables cease to exist when a block finishes executing – the computer throws out its only record of what values those variables had. You can read more about memory and execution in this article, which has some pictures to help visualize what’s going on.

What about static variables, if they live in the stack why don’t they disappear? My understanding is that they actually live in the heap (where stuff stays until you deliberately get rid of it), and what goes on the stack is just the address of where the static variable lives in the heap.

Scope might seem really simple if you’ve been programming for a little while, but let me throw a wrench into that idea: multi-threading. With multiple threads running the same code, it can be really difficult to figure out why on earth your variable suddenly has a value that makes no sense. Not that I’ve ever spent multiple days swearing at my computer for making no sense ;)

WordPress Appliance - Powered by TurnKey Linux