I had an interesting conversation recently with one of the junior engineers on my team about when to use type aliases. Normally when I get asked for advice I’ve thought about the topic or at least have a rule of thumb I use for myself. Here all I could manage to express was that I don’t use type aliases but not for any particular reason. I felt I should do better than that and promised to get some better advice and see what we can do with that.
Having thought it through a little, here’s the guidance I gave. You can use type aliases to do type refinement to constrain an existing type. So, you could constrain that integer to only positive integers. Instead of assuming that some arbitrary integer is positive, or checking it in multiple places you can push that check to the edge of your logic. This gives you better compile time checks that your logic is correct and that error conditions have been handled.
They can also be used to attach a name to a complex type. So instead of having an
being repeated through the codebase you can name it something more constructive to the case. This also allows hiding some of the complexities of a given type. So if, for example, you had a function that returns multiply nested functions itself like
String => (Int, Boolean) => Foo[T] => Boolean
it can wrap all that up into a meaningful name.
None of this is really a good rule for a beginner but it feels like it wraps up the two major use cases that I was able to find. I ended up going back to the engineer that prompted the question, with “use type aliases when it makes things clearer and is used consistently.” Neither of us were really happy with that idea. There are clearly more use cases that make sense but we weren’t able to articulate them. We’re both going to try it in some code and come back around to the discussion later and see where that gets us.
I had added this to my list of books to read a while back, then after seeing a copy of it in the office getting passed from person to person it jumped to the top. I can’t think of a specific anecdote from the book I think you would need to know, but I do think if you are involved in making software you should read it. It presents a sort of zen of software management where you ensure that those doing the work have the space and resources to solve the problem. It’s expressed in a lot of short chapters that mostly center around anecdotes from the author’s career as a consultant.
It talks about how to help spur innovation and motivate others. There are ideas that I had seen in practice from my manager about how to craft and express a vision. I specifically remembered the discussion of the vision since it was really effective and highly motivating. The template for the discussion came straight from the book. Initially reading the template I felt skeptical, I’m not sure if it was because I didn’t remember the usage of the template and it was tickling the back of my mind, or because it doesn’t seem good on paper. Having seen the results of it I am convinced.
There was a chapter about power conversion which seems to me the central idea. If you have power in one realm you can use it to express power in another realm by figuring out how to leverage your strengths. This seemed like the one specific point that I personally need to learn more about. I haven’t figured out how to do it yet, but I keep circling back to this particular idea as something I need to figure out.
It strikes me as a lot of Theory Y management, although it never says that. Since this is about leadership the act not management the title, it is applicable to both engineers who want to stay on the technical track and those who are interested in the management side as well. If you’ve got a strong grasp on the technical portion of the job and want to better understand how to expand your influence check this out.
How To Solve It isn’t a programming book. It’s not exactly a math book either, but you will find yourself doing geometry while reading it. It isn’t a book on logic, but it is all about structured thought processes. I would describe it as a manual to teaching a systematic approach to problem solving to others, using geometry and a series of examples. It tries to lay out all of the thoughts that whiz through your head when you see a problem and understand how to solve it without really contemplating how you knew it. It’s a fast read, assuming that you know the geometry he uses in the examples.
The problem solving process is broken into four basic steps: understanding the problem, devising a plan, carrying out the plan, and looking back. At first it seems obvious, but that’s thing about a structured approach, you need to cover everything and be exhaustive about it. For example, to understand the problem you identify the unknown, identify the data, identify what you want to accomplish, try to draw a picture, introduce suitable notation, and figure out how to determine success. If you wanted to know should you buy milk at the store this sort of formal process is overkill, but if you are struggling with a more complex problem like trying to figure out what’s causing a memory leak or setting up a cache invalidation strategy it might be valuable to structure your thoughts.
I haven’t had a chance to apply it to a real problem yet. I did use some of the teaching suggestions – how to guide the pupil to solve their own problems – with one of the junior engineers I mentor and it seemed productive. I got him to answer his own question, however not enough time has passed to see if it improves his problem solving abilities in the future.
Overall the book was an interesting experience to read and seems practically applicable to the real world.