Voice of the DBA

Tag: book reviews

  • Book Review: Lights Out

    I have always been interested in GE since I was a kid. My best friend in high school had a parent that worked for the company for a bit and liked it. The parent was successful and I had GE on a list of companies I’d like to work for as I went into college. I never followed through, but I’ve been alternately impressed and disappointed in the company for much of my life.

    I picked up Lights Out as a business related book that looks at the history of the company from Jack Welch as CEO to recent times. I had always wondered how would look back at Jack Welch over the years, after looking into the company and seeing how much of their success and profitability came from finance, not products. I knew this book might be slightly skeptical of the GE management philosophy, and I read it with that in mind.

    Early Days

    The book is a bit of a flashback. It starts briefly with the transition of the CEO role to John Flannery. It sets the stage that the company is struggling. From there it goes back to Jack Welch, his growth in the company and then the success through his reign.

    The book notes that a lot of the pressure he put on managers was to meet the external expectations of the public and investors. He expanded the role of GE Capital, their financial arm, using the tripe A rating of the industrial company to loan customers money and help finance purchases. This made GE a de facto bank, in addition to their industrial might, and helped stabilize poor performance in some sectors.

    It also allowed the high profits of banking to grow the company without the regulation and oversight banks have.

    Welch also added lots of companies, growing the breadth of GE’s business. At the same time, they turned out impressive managers who could run their businesses. While I always suspected that this wasn’t all true, this book talks about some of the pressures managers faced, the power of a conglomerate to help them hide some shortcomings from investors, while ensuring the overall success of GE continued. I think if I’d joined the company in 1990, I’ve have been at the tail end of a successful run. I also might have expected that dividend to continue through my career, which would have been a problem.

    Immelt

    Welch’s successor struggled. Not the least of which was after 9/11, but some of the success GE had before that was tempered with more regulation of the company as a pseudo-bank.

    I don’t quite know what to think of the GE of 2001-2017. As they tried to lesson their reliance on finance, grow into software, and continue to prove success to Wall Street. In some sense, I saw this as the slow decline of a company that struggled to reinvent itself and move away from some of the heavy industry and finance that had been it’s success story.

    I also think that the author misses some of the changing nature of the world. GE did learn to build better products that lasted longer. Even with the maintenance contracts, sustaining growth in power plants and jet engines would be hard. Certainly they haven’t been able to dominate in software, and it doesn’t seem that Immelt kept up managerial excellence.

    The book doesn’t quite dive deeply into the GE world, being more of a summary across time of what was published about the company and might be inferred.

    Overall

    I don’t know that I learned a lot about business here, other than what I’ve thought. It’s very messy, there isn’t a magic bullet, and you need a lot of resources to recover from the possible bad decisions and mistakes your management makes.

    GE is a success in some ways, but like one of the reviewer’s comments I read. It’s an American story, getting caught up in finance and money, not the basics of building a great product and selling it.

  • Book Review: Making Work Visible

    I was recommended Making Work Visible by a developer at Redgate Software. The book caught my eye as it seeks to ensure you can work more efficiently by watching out for some of the common things we do wrong in software development. It’s a DevOps related book, and many of the concepts of flow, work in progress, etc. that we talk about in DevOps are things that I saw in the book.

    The overall message is that there are five main time thieves that cause you to work less efficiently than you or your team might otherwise function. These are:

    • Thief Too Much Work-in-Progress
    • Thief Unknown Dependencies
    • Thief Unplanned work
    • Thief Conflicting Priorities
    • Thief Neglected Work

    The different issues are introduced early on, with each getting a few pages to describe them. Then later in the book, the author delves into more detail on the issues of this type of time thief, the impact, and ways you can think about working around the issues.

    I read this book alone, but I might recommend you work in team here and do some of the exercises shown in the book. Each is really a physical activity, but I’m sure it would work with a virtual meeting these days.

    The book is really built around Kanban boards, and there is a lot of detail on the ways to organize, or not organize, your board and team. I’ve seen some of the positives at Redgate, and some negatives as well, though I’ve seen more negatives at other companies.

    There are suggestions for meetings, techniques for informing others of status and progress, and even some “beastly practices. There is lots of information supporting why something is good or bad, or really, more or less helpful.

    I read most of this book in my Kindle app, but I did go through some in the cloud reader from Amazon. There are lots of images and illustrations, and lots of color, so I might recommend that you get the physical book, or if you like Kindle, read it online at times, especially with the examples and diagrams of the Kanban boards.

    For me, personally, I get caught up in unplanned work at times, but often I have too much WIP and neglected work. I start things and don’t finish them quickly enough, or focus on getting them out of the way. One thing I took away from this book is to slow down and dedicate more blocks of time to knocking items off my list, rather than doing some things when I feel like it.

  • Pro SQL Server on Linux–Getting Started

    As part of my learning goals for 2018, I wanted to work through various books. This is part of my series on Pro SQL Server on Linux from Bob Ward.

    I purchased Pro SQL Server on Linux and started reading it in December. I’ve been playing with the Linux version of SQL Server 2017 for a few years, but very lightly. Mostly I’ve just tested stuff I do on Windows to see what works on Linux. After talking to Bob Ward at our SQL in the City Summit events, I decided to dive in deeper and work through some basics as my knowledge here is spotty.

    I didn’t have a Linux machine handy in December while traveling, but I started to read anyway. This is a first look at what I got through.

    Why SQL Server on Linux?

    The opening chapter describes some of the history of SQL Server and how the version was built on Linux. Between MVP sessions, some online reading, and some other presentations, I’ve seen a lot of this, but it’s still neat to review it.

    To me, this is one of the more impressive software ports I’ve seen, especially since the core engine really is the same, with the code being shared between Windows and Linux. Microsoft is easily maintaining two platforms here in a way that they couldn’t do with Windows.

    Interesting to read.

    Install and Config

    I’ve done this a few times, but it’s good to go through. Bob covers some common Linux commands you’ll use, and it’s good to see these. While I read this without a VM, I vaguely remember some of this. Need to go through this when I get in front of a setup.

    The install of SQL Server is done a few times, a very high level, and then a more detailed look. There are also some troubleshooting references to review with lots of links. We’ll check this later.

    Chapter 3, 4, 5

    I bundled these as they are SQL Server basics that aren’t really related to Linux. Chapter 3 is about building a database and some T-SQL fundamentals. I know most of these, so I skimmed this one.

    Chapter 4 lets you build a basic Node.js app and connect. This also covers some advanted T-SQL structures. Again, for someone that’s used SQL Server for any length of time and tried new features, you’ll want to skip this.

    Chapter 5 is tools. I know most of the tools, though I’ll review the linux variants later.

    The First Half

    This is what I got done before the end of the year, reading on planes and during downtime. This is almost the first half of the book, but it’s a lot of pages. I’m looking forward to digging into more parts of the book during the rest of January.

  • Lessons from the Phoenix Project–Leave Slack

    Not @Slack, but slack time, time when you aren’t buried on a particular project.

    In the book, The Phoenix Project, the Brent character is the jack of all trades, the one that everyone goes to to fix and solve problems. He gets tasked with important projects and work, which means he’s always busy. I’ve been in this position, and a few of you are likely depended upon like this at your job.

    Slowly, the other characters start to realize that if Brent is fire fighting, or he’s on a long project, then he can’t get other things done. He likes and wants to complete work, something most of us do, which means that unless he has windows to tackle new work, he never gets to new work.

    It’s important to break work down and work in small windows. It’s also important to ahve some free time available for anything that comes up. That way if there is something important, you can tackle it without subjecting that item to a long delay. If you also find that some work can be handled by others or isn’t important, you have a break to switch to something else and leave the less important project behind.

    This comes from flow of work and theory of constraints, outlined in The Goal, from manufacturing. Ensuring that some resource is always busy doesn’t make sense from an flow standpoint. This is discussed in the book, Slack, as well.

    If you haven’t read The Phoenix Project, it’s a quick and easy read. A little silly, somewhat exaggerated, but it makes a point that’s worth making in how we work in technology.