These are questions for wise men with skinny arms

I have at least 6 side projects, this blog is one. That count doesn’t include crafty handiwork, maintenance, or learning a new skill. I don’t have a good term for those short sessions, as they are more of a spike instead of a storied endeavor. My side projects are ideas I enjoy working on, but not necessarily complete. I think the difference between that project time investment and the time spent on things like TV seasons, video games, and random social events is an interesting dichotomy.

I used to hate doing ops, it reminds me of doing front-line IT work when I had no idea what was going on and was constantly at the whim of a developer I could never contact or understand. Once I became a developer, I didn’t give ops enough credit until I did independent work. As a developer first, I favored build over buy because I’d rather make my own mess than spend time learning someone else’s.

I’ve been focusing on people management instead of just code development. The switch to human centric processes instead of machine driven requires a real change in attitude towards what is desired and acceptable. I’ve taken a serious amount of time and attention to automate and document all of my technical processes to eliminate as much human interaction as possible. I did this ostensibly to save time in the long run, but I started appreciating it immediately for the reduced mental overhead.

After my most recent F# work, I’ve gone back to working primarily in Python and other dynamic languages. I think I’ve picked up on quite a few new problems, but I’ve also seen that the type differences alone aren’t enough to make or break Python for me. Many of my complaints about F# were tooling and consistency related, and I think Python suffers from the same problems but in very different ways.

Throughout this long learning process of building and rebuilding a program, there have been a few consistent points that I’d trip over when using F#. Some were more noticeable at the beginning and others only became irritating after repeated use. Coming from C++ I’m used to avoiding language features that are more trouble than they are worth, so I was hoping the F# didn’t have as many or as nasty ‘gotcha’ moments.

This is the next step in my journey with F# in writing a small application. I decided to undo most of the reactive extensions work and get back to using simple functions wherever possible. I had let the project sit for long enough again to come back to it with fresh eyes. I saw where I could have made the FRP code more manageable by using bigger blocks in the data stream, but I was already committed to nearly start from scratch and apply everything that I had learned since I started in the hopes of having a complete solution from a single philosophy.

Learning F# as part of a real project is more than just the application code, it’s everything that’s involved with building up the system requirements to deploying updates. At this point in my adventure my attempts at working FRP into the solution weren’t proving fruitful, so I found it easier to focus on the rest of the ecosystem and other aspects of the solution. Testing There was an upside to creating a system that didn’t work; to discover why it didn’t work I needed a much more powerful testing framework than before.

This is continuation of my previous journal on working with F# in comparison to an existing C++ program and supporting Python systems. It ended on a still-prototype level system that was heavily OO, but used some of F#’s nicer type and syntax features to cut down boilerplate and organizational complexity. F# was easy enough to learn and use, but I was looking to push the system from a prototype to something more polished.

A coworker was talking to me about how difficult it can be sometimes to explain technical problems to non-technical users. Most users want to know how the system works, especially if it’s critical to their daily responsibilities, but it’s important for software developers to draw a line where the domain ends and the technical details remain. Saying a problem was caused by a key consistency error from something strange with Posgres sequences should not mean anything to a user wondering why restoring old data didn’t work.

I’ve previously mentioned a passing interest in F# because it was sufficiently different from languages I knew and had many concepts that sounded immediately useful. It took me almost 2 years to take the plunge and implement a non-trivial app in F#. It took 3 tries to get something that felt usable and idiomatic. This the first part of my journal of lessons learned. Starting out I didn’t buy any books or take any classes, but I did read every bit of literature online before writing anything at all.