High-level info about me
| Info Type | Info |
|---|---|
| Contact Info Email | [email protected] |
| Pronouns | He/him/his |
| What am I working on now (job) | Tech lead to multiple dev teams modernizing an on-prem application -- .Net/Smalltalk/client-server-- for the cloud -- Angular, Node, Oracle, Postgres |
| What am I working on now (spare time) | Using nights and weekends to add new language work to my Github account in repos containing fun toy projects |
| Fun fact | I once wrote self-modifying code in Apple BASIC so that I could graph user-defined formulas using high-resolution graphics. I'd officially learn "self-modifying code" is a thing and that some languages actually allow it, unlike my hack of BASIC, in college. |
| Social | Link |
|---|---|
| Substack | https://substack.com/@some1elsier |
| Bluesky | https://bsky.app/profile/tw33tzr4kidz.bsky.social |
Some tech leadership resources I created
My substack account contains examples of how I manage engineering efforts.
Presentations I made in the Boston area about engineering
| Name | What | Where | When | Link |
|---|---|---|---|---|
| Biting Gold | Ministry of Testing Meetup | Quickbase | Nov 7, 2018 | Biting Gold |
| Hoodwink Your Tests With Test Doubles | Boston Software Crafters Meetup | Pluralsight | Aug 28, 2018 | Hoodwink Your Tests With Test Doubles |
| The Epic Battle Between Folklore and Engineering | Boston Software Crafters Meetup | Pluralsight | July 23, 2018 | The Epic Battle Between Folklore and Engineering |
| Building Unit Tests - Python Restful APIs | Boston Software Crafters Meetup | Pluralsight | June 26, 2018 | Building Unit Tests - Python Restful APIs |
| Java and Test Driven Development: Red, green, refactor | Boston Java Meetup | Pivotal | July 10, 2018 | Java and Test Driven Development: Red, green, refactor |
| Learn Go and GoLearn | Boston Golang Meetup | DataDog | May 1, 2018 | Learn Go and GoLearn |
| Red, Green, Refactor: Test And Data Driven Development In Kotlin | Kotlin Office Hours Meetup | Intrepid Labs | April 12, 2018 | Red, Green, Refactor: Test and Data Driven Development in Kotlin |
Articles I wrote about design patterns and published on Medium
About my Python repos
This is just one of many interesting things about pythons.
- Don't assume code in the repos represents work which would pass a code review I help a team define, or which I'd implement myself.
- Standards differ, and I have worked within many different sets, helping to establish code standards, code-review methodologies, and to build on them.
Pay no attention to the man behind the curtain
Beginner work What you see here is some work I did a while back in Python, before I:
- managed a team of Python engineers
- tooled technical implementations with enterprise customers onto a SaaS system in Python so I'd automate the difficult parts away-- allowing me to have more information to talk to the customers
- became a tech lead for a project involving a customer moving to the cloud from an on-prem system, one involving Angular and Node
Back when I wrote these, I was quickly evolving my style from "able to solve complex problems in Python reliably" more towards "writing Python I'd submit for a production code review" or "Python I'd show a junior engineer when mentoring that person".
I'm was learning, researching Python-particular coding patterns (even learning from anti-patterns), to refine my code style. [I am still learning!] As time permits, I'd like to continue my work building on these.
On code smells
# I know what code smells are
I don't like code smells.
On the job, I'm ever-vigilant about them.
I do this side-work because I love Python enough to spend my leisure time getting better at it.
Why do I have Python code up here with bad code smells?
I want to demonstrate I can write a rough draft of Python code to do a variety of things, even if I write it hastily and promise to come back to a toy project to refactor it.
Some of this is Yoda-aged code for me! I do come back periodically and clean it up, but my checklist for good code and a good repo is very long-- sometimes I find new projects to work on!
Some of this code is just downright experimental:
- Some code is made in such a way as to stretch out what the code does along different axis. The early drafts are to get the code working, and the later drafts will make it conform to expectations more in how it does that thing.
- Some code was written deliberately hard in order to be a puzzle for my writing skills. I learn from these anti-patterns: in constructing the code and recognizing why it would be difficult to maintain.
In other words, this is my sandbox. You get a peek inside what I'm curious about. I move very fast and break a lot of things here, since I have limited evening and weekend time to move this work forward. I focus on getting to green, and sometimes that means the code is not refactored when you check in.
Code is only partly measured by how it performs as expected-- it should communicate, tell a story.
That's what I do during my work-day. I make sure code can ship: it produces the right results, it has quality, and it tells a story for anyone else who might pick it up.
As a manager and as a tech lead, I apply the same level of vigilance to it as I have over time in all the languages I've worked, and I would address the code during a work day when I'm still fresh (have coffee / tea in me).
On patterns and anti-patterns in general
But an engineering manager or tech lead looks at other patterns:
- Communication patterns and anti-patterns
- Organizational patterns and anti-patterns
- Work process patterns and anti-patterns
- People leadership patterns and anti-patterns
I have a couple of decades learning these the hard way so that they are instinctual. I love talking about them. If you can't find a topic covered in my Substack, hit me up.
I know each pattern is only a compass indicator: I don't let the perfect be the enemy of the good. If any org could perfect itself overnight, we'd all be out jobs.
I know how to drive teams to iterate towards better places without preventing them from shipping software along the way.
Disclaimer: Some of my better work is not on GitHub because it is protected by an obligation to one or more companies.
Thanks in advance for your patience with the works-in-progress and older work represented here!
To do list for me to revise and move to issues as needed
- Move gists from old GitHub account to current one
- Standardize repos with best practices in Resources repo