A commitment to $DOING_SOMETHING

Hey,

It's crazy how I've been nominally a user for THREE years and haven't done anything with this account -- and every day I woke up thinking another day will just slip by in my life, and one day I will die and regret the time I didn't spend doing something.

Well, I recently left my last job, and I'm excited to see what's next. I realized there's actually a good number of pain points I experienced in my career thus far, and maybe I can help fill those pain points (mostly revolving around developer tooling / infrastructure):

• I don't have a set of dotfiles yet, which makes setting up a dev environment and keeping it consistent difficult. It's also the simplest/easiest thing to get started and ship. That should be fairly straightforward to implement. Inspiration / leads: https://dotfiles.github.io

• I haven't yet encountered a great integration testing framework yet (something with side effects, yet remains fungible and idempotent). I personally would have benefited from something like a relational database store of possible execution paths, with each "path" modeled by a directed acyclic graph of services/nodes. This is high on my list, because while unit tests are nice production code always trends towards the properties of the underlying language / framework, and all code runs on a finite state machine.

• I like Apache Spark, and I'm certain I haven't tapped into its full potential, but a lot of times you have to work around the framework / language. Every language that binds identity/state using eager loading has to have a separate API for lazy loading data implemented at the framework level if you don't want to get out of memory errors, and you can call an eager API once in your pipeline and have the entire thing blow up and crash. I think that's kind of brittle. I've been exploring Haskell and even with the risk of having a programming language that's "too powerful" it might be well suited to pipelining bytestreams. Imagine a set of executable binaries that you can pipe in single-node UNIX, or a dask-like framework where you can pipe across network, that spills to disk correctly, and that's individually composable, to maximize the percentage of the framework that's DONE (ohmygodthatsoundsnice). It'd also be good to have something non-trivial to write in Haskell and vomit out the first 10,000 lines of bad code in.

• React-like functional UI composition library for the terminal, built on the ncurses API. After experiencing programming from the terminal (emulator) level, it is kind of crazy to see a GUI server stood up to support a browser to support a webapp. I tried one UI library in Python (Urwid) and it was a great way to get started, but felt jQuery-ish when it came to state management. I'd love for a way to have a React/Redux-like library to build beautiful UIs on the command line, to improve client accessibility/performance, have greater API stability, and improve client-level security.

• ISSUE TRACKING. I've used Jira in the past and while it gets the job done, I really wish there was some kind of a schema for any given issue, so that when requirements change, we can do some kind of migration in order to ensure that as few regressions slip by the issue tracker as possible. Even better would be something that's scriptable (not the UI) and composable (or a very well designed API, like API-first). It would be so wonderful to have much greater observability into any given project, and to be able to build that alignment even between engineering management and engineering, to say nothing of the sales|executive|engineering trifecta.

• I talked to one engineer about a tool he really enjoyed using internally, and he said in simple terms it was a framework that can issue lambdas on top of materialized views. I'd love to have something like that to keep in touch with my professional network (if now - last contacted > 6 months, send a lambda email to my inbox in order to remind myself to keep in touch). Losing touch with people is really painful, and it's great to have a community of peers to cheer us along.

I'd love to hear your ideas about what your pain points are, and how you might prioritize these ideas. They're the ones constantly bouncing around in my head right now, and no others do; but you don't know what you don't know, right?

(My goal is to write ten lines of code a day, and forgive myself if I don't. It's crazy how I've written tens of thousands of lines of code in the past few years, but my personal projects pretty much don't friggin' exist, and how if I wrote 10 lines of code a day for 365 days I would have 3,650 lines of code a year written. I want to really like coding again, and I'm cautiously optimistic implementing AND SHIPPING some of these will help that cause.)