Category: Editorial

  • Making Software Decisions

    I work for a company that builds software. At Redgate, we are constantly debating what to build and how, and more importantly, how to structure something that is easy for our customers to use. There’s a lot that goes into the process of building software, way more than I thought was important a decade ago. Today, even when I don’t like the decision or the final result in a product, I know our process often produces good results.

    Recently Netflix started a new series on how they make decisions for their software. It’s interesting in that they note that of all the ways they can make decisions, most of these involve few people. This leads towards their premise of using lots of A/B experimentation for helping to make decisions, and I look forward to future parts of the series that might explain the weight that they give to the results of A/B testing versus the opinions of developers and management.

    How do you decide what decision makes the most sense for your business? I often see technology professionals being very passionate about how or why something should be implemented. I also think that sometimes we lend more weight to the passion of the arguer, rather than the merits of the particular thing being examined. It’s easy to give in and go with the group, or not care, about many software decisions.

    For me, I’ve learned to try and give feedback, justify this with some rationale, and then trust the process. No matter how “right” I think I am, we are a team, and if the decision is made to go a different way, I support that. I’ve also learned that building software involves a lot of tradeoffs, especially with regard to the prioritization of work. There’s always more work to do than can be completed by our staff, no matter what the size of the team.

    I find the process of building commercial software to be fascinating and I’ve learned a lot in the last few years about how to make the process successful. I’ve also learned what Netflix talks about. A small group has a very limited viewpoint and it’s worth gathering more data whenever possible to ensure you make a decision that has a positive impact on your software.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Thank a Mentor

    “The delicate balance of mentoring someone is not creating them in your own image, but giving them the opportunity to create themselves.” — Steven Spielberg

    I saw that quote posted on Twitter with the request that people tag a mentor that had helped them. Since then, a few people have posted their thanks to someone, and I’ve been tagged a few times. I’m honored that people think I’ve helped them somehow, as that’s been a portion of my career for the last twenty years. I make an effort to do help others have a great career and become better at their jobs.

    I’m not looking for lots of people to post anything about their mentors here or thank me. Instead, I am asking that you stop and thank someone that has helped you in your career.  Let them know they made a difference and how they did so. It’s good for them and for you.

    We all need help, support, and encouragement at times to help us move forward. We can all use someone that can give us an independent view of our decisions, our choices, and more. Their thoughts and observations help us keep perspective on the way forward that best suits us. Certainly, I know I need the perspective, as well as  the advice from others.

    There have been many people who have influenced my life, but two that have made a huge difference in my career are my wife and my former business partner. Those are people I’ve talked with nearly every week for the last twenty years and who have influenced me more than anyone or anything else in my life.

    Life can be challenging at many times and finding the right path forward for ourselves can seem uncertain. A mentor can be an advisor, confidant, cheerleader, and support system. When you find someone(s) that meets those needs for you, treasure them and be sure to thank them for impacting your life.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • To Inifinity and Beyond With 1=1

    There is one thing that Aaron Bertrand won’t get mad at me for doing and that’s creating an infinite loop with a WHILE (1=1) pattern. He wrote about this recently in a tip, noting that it’s easy to create an infinite loop with code like this, something that never ends well.

    I have purposefully written infinite loops in the past. A long, long time ago Radio Shack would put out TRS-80s on display, and a few of us would type a quick BASIC program to perform some math work on the screen over and over with an infinite loop. It crashed at some point with an overflow, but for a period of time, it would look neat on the screen. Less neat to the salespeople who weren’t always sure how to stop it and demonstrate something else without resetting the machine.

    I’ve also created infinite loops by accident at various jobs. Those experiences have left me a little concerned about any loop that doesn’t have a defined time to end. I usually use a technique similar to Aaron, ensuring the loop ends. If needed, I add a call that can repeat the entire process if more data needs to be updated after the current loop ends.

    There are plenty of people who spotted the error in the code and think they wouldn’t create that problem in their looping code. However, I think few of us work alone on code for an employer, across time. Often someone else comes in to refactor or “improve” our code. The next person that adjusts this loop might join back to the main table and not realize they are creating an infinite loop. You’d hope they’d test this and find the problem, but I continue to see lots of “little fixes” deployed without being tested.

    This is one reason I want a DevOps style process for database code, complete with automated testing. If you write a piece of code, you are responsible for including a test in the pull request so that the CI system can verify your code passes the test. This isn’t a perfect system and it might not prevent all bugs, but at least a test will exist and someone can then check both the code and test and perhaps use the issue as a teaching moment.

    We try and avoid loops in SQL Server, but that isn’t always possible. As with most techniques in programming, we should strive to learn the best ways to use them, know the weaknesses, and avoid building code that has major flaws now. Maybe we also ought to add that we should ensure our code doesn’t lead less experienced developers in the future to make simple mistakes. I’d say the 1=1 looping code does this, and I agree with Aaron; it should be avoided.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Poor Work Management

    The future of how we will work is uncertain. Every time I read something or talk to someone, I hear different thoughts and experiences, which influence how I feel. Actually, I’m not sure how I feel. Some companies are pushing back their office openings (Google, Microsoft) to a future time, while others are bringing people back part or full time. I had lunch with some friends working at a financial institution, and they are allowed to work at home a day or two a week, but otherwise, they’re in the office every week. I know some other people that are back in the office five days a week.

    There are mixed feelings among many people. While I don’t know many technology people that want to be in the office every day, some do want the option to go periodically to the office. Depending on your commute, you might feel differently, as there are plenty of data pros that want to remain at home full time. Both groups, however, feel that we can be effective at our jobs while working remotely.

    Not all management feels thtat same way, for various reasons. I ran across this piece that speculates that poor management is more likely to fear remote work than embrace it. The example in the piece, from Cathy Merill, certainly seems to indicate this is the case. While I’ve seen some great managers, I feel many managers aren’t good at adapting to dramatic changes and struggle to change their own view of how to do their job.

    I do think culture suffers when we can’t get together in person. Hallway conversations and chats over coffee aren’t as easy remotely, and we don’t build the same bond we get in the office. Working separately at home can work, and we’ve had a lot of success at Redgate, but I also feel more separate from lots of co-workers and miss the chance to get together and catch up. The remote meetings are not the same, and scheduling a quick call is much more of an intrusion than being able to walk by someone’s desk or stop for a minute when I see them in the hall.

    Perhaps it’s the energy from being around lots of people that CEOs and other management miss. It can be invigorating and exciting when lots of people are working together towards a common goal and succeeding. Perhaps management prefers to look someone in the eye and put pressure on them for a lack of performance. That is harder to do virtually, and I know lots of managers that work through intimidation.

    There’s also the investment made in offices. Over the years I’ve seen various configurations and amenities in offices, often to encourage more work and comfort away from home. I know plenty of CEOs and leaders that feel this investment needs to be used by staff for lots of hours each week because of the cost, which seems like a poor excuse to me. That money is spent. These days I suspect more employees push back on longer hours, as they should, and find comfort at home, which might also bother management.

    This issue is complex, but I do know that whether we’re remote or in an office, we can be effective and get work done in teams. Management should know that and use it to try and build an environment that gets the most out of all their staff, whether in the office or remote.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.