I do mostly backend development and will do it in any language or framework. I love learning new things and if given the choice will always go for the unfamiliar framework. But I also find “use boring tools” to be a valuable guideline, and that the right choice for most projects is the technique that people working on it will already know. There is a contradiction here and navigating it is one of the more engaging parts of software work.
I’ve worked professionally in node, typescript, php, clojure. In my personal projects I use various lisps (clojure, racket, fennel) plus ocaml and sometimes elm. I originally learned to code in ruby and still love it, though I never got around to learning rails. I’ve been looking for a reason to learn erlang or elixir. I don’t think functional programming is an inherently superior approach, but I do find it closely fits how I think in code so I lean towards it when it fits the problem.
I’m particularly driven by helping peers: automating frustrating work, empowering non-programming coworkers with code-adjacent tools, querying data to answer business questions, or building and improving development tooling. I’ve taught programming professionally and loved it, my ideal job would have a fair degree of mentoring or teaching in it. I have a bit of an affinity for legacy code, and genuinely enjoy working in legacy codebases, when given support and clear expectations within them.
I’m a solid user of postgres and find it possibly the most powerful tool I get to work with regularly. It’s big and kind of a snarl, but I’ve gradually come to the conclusion that many webapp backends could be mostly replaced by a very well-configured postgres instance and a thin api wrapper.For example what postgREST is doing, using rls and pg roles to completely replace the auth layer. I’m very interested in seeing where these ideas go, and possibly improving the tooling around them which can be one of the biggest obstacles right now.
I’m also curious and excited about how sqlite is being adapted and used recently. Particularly with so many frameworks focusing on “at the edge” and horizontal scaling. My first love is postgres but I genuinely think sqlite is a better choice for many projects.
But I am not a dba. I know how to write pl/pgsql code and unit test it with pgtap, but not how to configure point in time recovery. My focus is on using the full expressive power of the db as a programming tool, not in managing it as a resource.
Show me a frontend dev who can built a redux store and I’ll show you a frontend dev who doesn’t know how to use a
<section>.
I’ve been ostensibly “full stack” in most roles, but in practice my frontend work has been framework heavy, particularly in react and vue. I’m comfortable enough in css to make modifications as part of other work, but I shouldn’t be trusted to build out a frontend by myself. Happy to learn more but I haven’t had very much need or opportunity so far.
Similar feelings about testing and frontend build tools. I’m comfortable modifying them or adding test cases to a suite. But deciding on an approach and building it out from scratch is a specialist domain I don’t have much experience with so far.
I value working as part of an intentional team. I’m really fascinated by some research, and my own observations, that what makes for effective teams is a sense of individual psychological safety. When people feel comfortable showing ignorance and making mistakes, and know they won’t be punished or shamed for it, they experience more freedom to accept challenges and attempt bold solutions.
I think most teams could benefit from more intentionality about their structure, process, and dynamics. It’s easy to conflate that with formal process though, which leads teams to believe they already have or don’t want it. I like thinking about and engaging in this literal team-building, and have always managed to have a positive impact, even as I’ve discovered that almost no single technique or process is universally valuable.