SJGP Software

 SDM Insights: Protect Your Team In celebration of my fourth anniversary as a Software Development Manager (SDM), I've written a series of reflections on some lessons learned. See the full list  here . My team has been 100% remote from day one, with developers in multiple countries and time zones around the world. So we communicate a lot with online tools like Slack and Skype and Zoom. This lets the team better collaborate, and also gives a direct connection between Support and Development. Too direct, it turned out. Often Support would encounter an issue with a Client and ping the Development team. If no developer responded quickly enough, or if the issue piqued her interest, the Product Manager would regularly jump in and assign a developer to investigate the issue immediately. Everyone would then wonder, at release time, why the Development team was only able to deliver a fraction of the expected new features and fixes. The problem was in part a process that was too open to...

SDM Insights: Own the Failures - Yours and The Team In celebration of my fourth anniversary as a Software Development Manager (SDM), I've written a series of reflections on some lessons learned. See the full list  here . About 6 months into my time as SDM, I had to kill a major project, one that had seen three developers invest many months, an entire year for the Senior Dev on the project. The project was the baby / brainchild of my predecessor, and everyone assured me that it was almost complete, just a little more time and effort would get it over the top. SDMs are not always in the position to green-light or kill significant client-facing projects, but as we made our strategic plans for the coming year for Development, it became obvious that we had higher priorities and more lucrative opportunities to pursue, ones that we would miss if we continued to pursue this overdue, over-budget, over-complicated project. So it was terminated, and I reassigned the three Devs to other projec...

SDM Insights: Revise your definition of Success In celebration of my fourth anniversary as a Software Development Manager (SDM), I've written a series of reflections on some lessons learned. See the full list here . Separating the two halves of my IT career is a 9-year hiatus, most of which was spent as an Anglican priest in a small, rural parish. Despite knowing better, I internally defined my success by the attendance and financial health of the parish. So as people aged and died, and weekly attendance and giving slowly shrank, my frustration and sense of failure grew. The fundamental flaw was that I was using the wrong definitions of Success. As a developer, my definition of Success was more oriented toward the tasks I was assigned. Was I delivering them on time? Was I increasing the test coverage as I did so? Was I meeting and exceeding my targets for fixes and new features? Was I out-performing the other developers? Those definitions were a mix of qualitative and quantitative,...

 Four years ago this week, I started my exciting new adventure as a Software Development Manager (SDM)! It is now the longest time I have been in a single position in technology. My longevity is due in part to how much fun the role has been. I have described it to others as "the most fun I have ever had for a paycheck." In celebration of the anniversary - and new personal best! - I will distill some of my reflections on the nature of the SDM role into a series of short posts. I am tempted to call them the "5 Commandments" but that implies a completeness, that there are only 5 important things. Which is not true; managing a development team has so many factors that matter, not least of which is a depth and breadth of technology understanding.  These are the non-technical topics that I want to cover: Revise your definition of Success Own the errors and failures - yours and the team's Protect your team Know your Domain Management and Leadership only overlap And a f...

Since the words "Technical Demo" can be off-putting, both to the demo-giver and to any non-technical stakeholders in the audience, my teams often call them "Show-and-Tells" - they are opportunities to show progress and changes, evolutions in the system or interface, and more. Why We Do Show-and-Tells At the end of a Sprint, we want to pause and look back on what we accomplished, celebrate our efforts, and even to show off a little, to key people and stakeholders outside the Development group. The Show-and-Tell time lets us do all those things. Since we do not always know what each other is doing, it is a chance to show the team. It is also a chance to show our work to the Product team, the Testers, any Support and Implementation groups, and Sales and Marketing people. It’s a great way to: * show a finished feature * show progress on a multi-sprint feature * show before/after behavior of a fix * raise questions needing input beyond tech team The Show-and-Tell leads n...

  The Problem We want to gather information about the same data entities, scattered across diverse schemas. How to apply the same SELECT query in each schema and gather the results into a single output? A sample Use Case: we want a list of user login names across all schemas, so we can analyze possible conflicts in moving to a centralized identity management system. MySQL Cross-Schema Reporting Screenshot of results of this process, from MySQL Workbench: Our approach is to create a stored procedure that will walk through all schemas on the server, run the same query to gather the data, and put the collected data into a dedicated table in an administrative schema for future reporting and analysis. First, let's create a new schema for this Reporting exercise, and select it as the schema in use. CREATE DATABASE CustomReportingSPS; USE CustomReportingSPS; Next, create a table that will collect the results of the query as it is run across schemas. CREATE TABLE rpt_active_users (   ...