Bill Karwin’s name precedes himself, as he is among the top 0.01% of StackOverflow users, and the online community perhaps knows him best for his generosity in sharing information about relational databases.

Today he works for Square–the enormously successful payments business–from his hometown in Santa Cruz, California.

Bill joined us to share some of his personal background in software engineering and advice for those who are just beginning their career journey.

Bill Karwin

Audio:

Play in new window || Download

Show Notes:

Transcript

Max: Hi all, Max of the Accidental Engineer, here. Today we are joined by Bill Karwin–Bill is a tremendous contributor to various highly visible public websites, like Stack Overflow, Quora.

Do you mind introducing for our audience, a little bit about your background?

Bill: Sure. Thanks for asking me here, Max. I’m glad to join you.

Max: Absolutely.

Bill: Yeah, I’m a software engineer by training, and I’ve been doing this for quite a long time. With the theme of Accidental Engineer, I fell into doing database work accidentally a while back, when I was working as a technical support engineer for a database product called InterBase. As I learned more about databases in that role, I started getting exposure to lots of people using databases in different ways for their applications and I started realizing, it’s really the foundation of virtually every application that we develop. It always has this sort of data layer, and it’s a very common kind of element.

Max: Yeah, I agree. It was of the computer science classes I took in my undergraduate degree. I majored in math, but I took a number of computer science courses. I tell people that database systems is the most applicable course I got in my undergraduate degree. Just learning SQL and learning some basic database interactivity tools. Totally agreed with you on that front.

You’re coming up on a 30-year career in software engineering, is that right?

Bill: Yeah, if you count all the way back to doing internship work while I was in college.

Max: In college, you majored in computer science, is that right?

Bill: Yes, I went to University of California, Santa Cruz. I got my degree in computer science. I had that as my plan from way back. I was getting interested in working with computers back in high school, and doing a little bit of programming back then on the Apple II, back when computers were one megahertz, literally.

Apple II

Max: What was it like trying to write software for computers back then versus today? Maybe it might seem obvious to you or I, but for our audience, what was it like back then?

Bill: Oh, sure. A lot of things are different about that environment. There’s no hard drive, so you’re working on your code in memory only and when you say, “Huh, it’s been an hour, maybe I should save this,” put in a floppy disk. Save it to the floppy disk. Now it’s safe.

But in the meantime, you’re in a text editor writing this on the fly, and if you lose power or something like that, it’s gone.

Of course, code has to be very small, because the computer capacity is very small compared to what it is today. You have to start thinking about how to do things very, very efficiently, writing more logic, fewer lines of code and trying to utilize the resources very carefully.

I wrote a pretty detailed program back then to do a spinning globe of the world in 18 kilobytes of RAM. I had to do this complicated thing like I’m painting the globe into high memory and then when it comes to showing the globe moving, you tell the computer, “Okay, your display is now using this memory, just shift the entire display up to this area of memory.”

A lot of creative things go into that, when you have such constrained resources. Today, people say, “everything’s so huge, don’t worry about it, we have terabyte-sized hard drives, we have all these gigabytes of ram.” But we are where everything old is new again.

We’re now designing software for things like mobile apps,the Internet of Things, embedded devices and things like that. There are people designing software to run on these tiny, tiny platforms today and I recognize all the skills that they’re developing to do that sort of thing from when I used to use micro-microcomputers.

Max: Back when the Apple II came out was it a pretty expensive computer to buy? In contrast to the purchases that people make today for computers?

Bill: In some ways, yeah. The dollar figure was pretty comparable. Roundabout $1500 to $2000 has been about the price of a personal computer since the very early days.

That figure was more valuable back then because of inflation, so it seemed more expensive but it’s interesting to watch over the years that the price of a mid-range personal computer in dollars pretty much has stayed about the same for a long, long time.

Max: Was that an issue for computer science programs like the one you attended at UC Santa Cruz? Was it hard to find a computer lab with enough computers to go around for everybody in your class?

Bill: In high school, we had Apple IIs and everybody had one. There was probably about 24 computers and that was a pretty big deal at the time. That was like a county-wide program that bought those computers.

In college, we didn’t use personal computers so much as we used a Unix machine in an interactive, or shared environment, where everybody would have a serial terminal that’s essentially just a monitor and a keyboard that is connected by a hardwire all the way back to the shared Unix computer.

We would have dozens of people sharing on the same environment, and that was an interesting precursor to the whole social media movement that is common today.

Just because we were all interacting with each other, even though we were on the same host. It feels like you’re distributed because you’re all in your own separate rooms with your terminals or people were on dial-up. We were able to share information or post things to each other or run applications together and you had this sort of BBS style applications where you could communicate. That’s the early, pre-web version of Facebook.

Max: In your first job, the internship that you held when you were an undergrad student, was it the same setup with the Unix terminals for everybody to interact with the same server?

Bill: Yeah, my internship midway through college was at a company called the Santa Cruz Operation or SCO. They were a company that made their own version of Unix for Intel PC type of hardware and it was pretty innovative at the time.

Now, everybody has Linux, and it’s pretty common. At the time, that was something which some people told them they couldn’t do. People like IBM and other big companies said, “No, no, Unix has to run on an expensive, big machine that we sell.” But SCO tried to make their Unix on commodity, cheap hardware.

I joined them as an intern in an application development group. We were working on a spreadsheet application. Back then, the computers were things like 286 and 386-based processors,you could say, “Okay, team, you’ve done your coding for today. We’re going to compile the code that you wrote today. Everybody go home. It’ll be done in the morning.”

I mean, it would take several hours to complete the compile of one run, and you’d come back in the morning, and resume the next leg of your development network.

Max: People today often complain about the old times but in the case of your internship and your jobs after college, did that provide bookends to your workday? When somebody announced, “We’re going to compile now,” did all of you guys pack up and go home at a reasonable hour?”

Bill: Oh, yeah. You can still do other work, research, reading, testing, planning out what you’re going to do the next day, communicating, having meetings, catch up on your email. All those things could be done after you set that going, so it wasn’t necessarily that you clock out at that time.

Max: After graduating, you joined Borland? For people who aren’t familiar, do you mind sharing a little bit about your experience there?

Bill: Yeah, Borland was another company local to me. It was a good place to go, and they were a big name back in the 1990s for developer tools. Some people still use some of their tools, like Delphi, which is an IDE, sophisticated editor for doing visual programming and putting together applications in that way.

It lent itself to non-web applications, desktop-type applications that you would use for a Windows machine for example. It was very popular and very innovative in its time because you could put together user interfaces very quickly,drag and drop kind of things.

Here’s a form control, here’s a grid of data, here’s a button and then link up those buttons with little snippets of code that would have to do actions based on what happens when you click the button. It was a really popular thing for people who wanted to do rapid software development.

Nowadays, we have other IDEs, like IntelliJ, Eclipse, NetBeans and things like that. They give the same kind of feel and they have different types of strengths but at the time, Delphi was a good leader.

Max: I think a large portion of our audience would benefit from hearing about the types of roles you held. I know you held diversity roles while you were with Borland. Do you mind sharing about that role?

Bill: Yeah, I had kind of an inspiring moment when I was a young engineer. I worked for a small company where everybody had to wear many hats to do their work and we were in just a one-room studio and I said, “Wow, someday I’d like to be able to have my own business and do that. What do I need to learn, in terms of diversity of skills, to do that?”

I deliberately sought out different things to do throughout my career to try and get a perspective of what it takes to run a software business. Not just as a coder, a software developer but how do you do IT? How do you do support? How do you do technical writing? And I put that into practice at Borland.

At first I was a technical support engineer, helping customers on the phone and by email to use our database. Then I moved from there into training, so I helped to develop and deliver presentations to do training for SQL and database work, database design, queries and all that sort of stuff.

I started getting into doing presentations at conferences from that and the first few times I tried to do a conference presentation, it was a complete disaster.

Max: How’s that?

Bill: I did not realize at the time the value of things like practice. The biggest thing you can do for your success of making a good presentation is to practice it beforehand. Literally stand in front of a mirror and go through the entire hour-long presentation, speaking as though you’re speaking to an audience.

There was a good coach who gave a talk at one of the conferences, to tell people how to be a better speaker and he said he would go through and practice his presentation up to 20 times himself in a room. He knew every line, he knew every slide transition, he knew all the jokes he was going to tell and his performances were flawless. It really helped to engage the audience.

The other thing he said about that was, be enthusiastic. Don’t come in there and say, “Here’s my work. I’ve optimized some code, and there’s the”. No. He comes in and there and says, “I’m going to tell you about the greatest thing that I’ve done with this code and you’re going to be able to do it too by the time you listen to me.” Now you’re engaged.

There’s a lot of these sort of complementary skills that you learn about being in the field of software engineering that are not just coding. It’s about communicating. It’s about getting other people engaged with what you’re working on. It’s about expressing leadership and enthusiasm for the work that you’re working on.

Max: Those are some tremendously valuable soft skills that you got in those first few roles with Borland. One of the things you’ve mentioned to me before coming on the podcast was about how,you got the opportunity to deeply learn SQL, which is how I originally came across you I think years ago, I first read your answers on Stack Overflow about specific use cases for SQL. Do you mind sharing for our audience how those roles in support, and training, and technical writing lead to learning SQL?

Bill: Oh yeah. I’ve been answering questions on Stack Overflow for a long time but I did other areas online, answering questions for people, back mailing lists and online forums and things like that.

The other way to practice SQL was, in the technical support team for InterBase. We had our own internal ticketing system, like how do you keep track of which customers you’ve helped and what did you tell them and what’s the status of this? We have dozens of customers and we have to keep track of that. Any kind of environment that has a ticketing system.

Ours had no application. We got into a query tool and we would write SQL queries to say, “Oh, well, we had a new call from Customer 123, better write a SQL insert statement into the database and record a text description of what we talked about.” We got a lot of hands-on experience every day writing SQL queries on the fly. There was no user interface. It was just command line, write a query, update the database directly.

Max: I know one of your open source contributions was to write a Perl driver for SQL, to somewhat more automatically drive your query?

Bill: Right because of that experience of writing all those SQL queries by hand, I said, “There’s got to be another way.” That was right about the time in the mid-90s when web applications were just starting to become a thing that people did and Perl was a really popular language for doing that at the time, CGI scripts and so on.

There’s a need of getting those CGI scripts to communicate with a database, I wrote a Perl extension for the database that I was supporting, InterBase and I wrote it in C and Perl, a combination of those two languages.

From a Perl script, you could connect to your database and submit that query, get data back and forth, commit transactions. Which seems like a common de facto work today, at the time, that connection didn’t exist for Perl.

That code that I wrote in C is still part of the Perl driver for InterBase. I released it for open source, it got picked up and added to what the standard database interface for Perl is, the DBD driver and that is still in use today.

Max: That’s awesome. We had a guest previously who is similarly about 30 years into the software engineering career and he made a comment that made me scratch my head. That none of his code that he wrote 20 years ago is in use today. I think it’s awesome to hear a case whereby you contributed to open source and broadening which might be using the code you wrote. The statement about the code you’ve written 20 years ago isn’t in use is false in your case. I find that just awesome.

Bill: Sometimes it happens in the most unexpected ways. The things that you think are going to have longevity end up getting replaced. The reason you think they have longevity is because they’re very useful but because they’re very useful, they end up getting used by more people and then get replaced by something with more features just because they’re so popular.

Max: Got it. It’s not necessarily,a sign that your code was bad, it might be that it’s a hot area of development.

Bill: Exactly. The people are more interested and they say, “Well, can it do this, can it do that?” Eventually they say, “Maybe we should rewrite it all in Java.”

Max: Fair enough. One of the things we didn’t mention is your role today. You are a database developer with Square, is that correct?

Bill: Yeah, I work in a team of other database administrators, database developers at Square. The company that does payment processing for those little iPhone gadgets where you can swipe your credit card across.

They have other products too,and we take on a pretty challenging role of being the centralized database administration team. Working with MySQL, Redis, and MongoDB all together to support many, many other developers within the company.

All the other developers are concentrating on their code and they just delegate the work of keeping their databases running to my team and we have a much smaller team of people who do that. The way to make that work is to automate everything.

We spend a lot of our time developing tools to say, “I want to upgrade the server and I want to upgrade 500 servers at a time.” That’s the kind of things that we need to automate.because there is no way to do it with a single human being doing all that work.

Max: For many in our audience, they may not ever have the opportunity to self-host a database. On the podcast previously we had the ex-product manager for Heroku Postgres which is their hosted PostgreSQL offering. He had some really interesting things to say about your type of role as a database developer,hosting manager and administering databases, is that it’s like treating these databases like finite state machines.

Bill: Yeah.

Max: That managing the state between 500 databases can be quite difficult.

Bill: Yeah, the buzzword that I hear a lot, they say, treat your databases and servers like cattle, not pets. And the metaphor is meant to say, if you treat them like pets, you’re spending a lot of time with them, you’re interacting with these databases on an individual level, you’re tuning them very finely and taking care of them, making sure that they’re happy.

If you treat the sort of collection of database servers which could be hundreds or thousands of servers, as a collective. Now you have to treat them all equally. None of them can be unique. They all have to be configured the same way. You end up doing operations that can be applied to dozens or hundreds at a time much more easily.

Max: We’ve talked previously about the topic if what skills should younger folks in their careers focus on acquiring. It seems relevant to the topics of different databases you mentioned. You mentioned MySQL, Redis and MongoDB. You have SQL and you have NoSQL databases. I was wondering, for our audience’s sake but what’s kind of the difference between working with those two types of databases, SQL and NoSQL?

Bill: I see that question a lot. When people are starting out, they’re wondering, “Which one should I learn?” It’s always challenging to face all the options that we have available to us and say, “I can’t decide how to specialize.”

There’s literally no way to learn everything that’s out there in the market, there’s just too many technologies. That’s okay, don’t panic.

The choice between SQL and NoSQL is very easy. SQL. I’m joking a little bit. There’s a lot of good things to say about both and I often use an analogy to maybe a carpenter or woodworker.

You go to a woodworker, and you say, “Which is better, a hammer a saw, or a drill?” he carpenter says, “They’re used for totally different things. Why are you asking me to choose one over the other?” That’s the same thing with technology.

You need to learn how to use the tools in order to understand when to apply them to different situations and the situations where a NoSQL database is going to shine and be the best solution is going to be a quite different situation from a relational database or using SQL. They’re not a replacement for one another, despite what MongoDB marketing might be trying to tell us.

Max: I just got an email, this makes me chuckle. Earlier today, I got a marketing email from a service that provides automated handwritten postcards and it was an email boasting that MongoDB had increased their engagement rate with prospective customers by 5X by switching from printed postcards to handwritten postcards.

Bill: How does MongoDB help with that doesn’t make any sense.

Max: Postcards? Well, I guess they have a sales team and they have adoption goals or sales targets, for maybe hosted offerings or consulting. They must have some sales team that engaged an automated handwriting service which emailed me out of the blue.

Bill: Okay, my computer scientist hat is tingling right now because you’ve just changed two variables. You’ve changed the database technology that you’re using and you’ve changed the method of communicating with your customers by moving to handwritten cards.

Which one of those two changes resulted in the increased engagement with their customers? It’s a bad scientific test because when you change two different things independently, you don’t know which one of them was the thing that gave you the benefit.

Max: The automated handwriting service was using MongoDB as a case study of a client who had used their handwriting service with great success in marketing MongoDB.

Bill: Oh, okay.

Max: It was less about performance and more about performance marketing.

Bill: Okay.

Max: I just found it humorous when you were mentioning MongoDB to mention that quite recently, I was on the receiving end of some of their sales gimmicks. But, no, besides the which use case, is it better for SQL versus NoSQL.One of the skill sets that you mentioned to me previously that I agree with being worthwhile for people early in their career to get deeply familiar with is source control. I was wondering if you could mention a little bit about why that came up and discussing valuable skills for people that are early in career to learn.

Bill: Oh, absolutely. Source control is one of the first skills that you should start practicing when you are getting into writing code. Source control is allowing you to save your work at intervals so you don’t lose any of it, but also that if you make some changes to your code and you say, “Hmm, that didn’t work out the way I thought it was, let me roll back to what I was working on yesterday or the day before that,” or whenever you want. Then source control saves every version of the code that you wrote, you can revert in any way that you want. This is how every professional coding operation works. It’s especially useful if you’re working with teams of people but it can also be useful if you’re working solo.

Max: Makes sense. In your career, did you start first using it in your first job, in your internship or at Borland? Was there a point at which source control became a more popular part of employers’ toolkits?

Bill: Yeah, I mean, it dates back all the way. There have been source control tools available from the very earliest days that I’ve been working with computers and it was necessary to do that if you wanted to work in a team.

Another thing you can do with source control is to create what they refer to as branch. You can be working on experimental changes to your code in sort of an isolated copy of the code that you’re doing on your computer and meanwhile the rest of your colleagues, your team, they’re working on the more stable code that isn’t in danger of being upset by your experimental work.

They can continue to work on that and then when you’re done with your experiments, and you say, “Now it’s stable, I can now share with you what I’ve been working on for the last five days,” then you can take your branch and re-merge it back into the mainline copy of the code but in the meantime during those five days, you can be committing your code and saving bits of it as you go, so that you don’t lose anything of those five days of work that you’re working on.

That’s important, to be able to avoid lost work. It gives you more assurance that your code is backed up and safe and if you need to revert to what you did yesterday, you can do that or compare to what you did yesterday. You can also show your teammates what you changed because of those different versions of code, there are tools to say, “Now show me everything that’s different between what you’re working on and what I’m working on.” And you can visually just see that in one place.

It’s a very important part of software development these days, and it’s been dating back for a long, long time.

Max: Perhaps a second order need or skill that people might learn at some point in their career, is automated testing. I was wondering, you probably witnessed the rise of the extreme programming movement. I couldn’t say when that was or when that occurred but I remember my familiarity with test-driven development was from a movement of software engineers pushing for testing everything or writing failing tests and then writing the software to pass those tests. What was that movement like? Did it affect your job at the time that it was going on?

Bill: I was aware of it, the extreme programming and test-driven development. I still see people advocate for it but I haven’t embraced it myself. I have embraced doing testing and lots of unit testing but I find my pattern is more okay.

I have a rough idea of what I want the code to do. I’m going to write sort of a skeleton of the code, like with classes and functions of what I want to do and then I’ll switch roles. I’ll then write some tests, some simple tests just to make sure that things start working the way I want them to and to set up the test classes so that I can run them from time to time but the tests don’t do much.

Then I’ll switch back to my code and I’ll start fleshing out more of the classes and methods and implement more pieces and switch back and forth to the testing. As I go, I’ll be bringing both of them up sort of in parallel but focusing on one at a time, either code or testing. Over time, as I get closer to the end of that particular task or project. I’ll be writing more tests than code.

I’ll be writing lots and lots of tests to try to drive out every little nuance of functionality and then occasionally going back into my code to say, “I didn’t think of one thing, I just need to change this one thing, or fix a bug.” Then I’ll get back to the tests. It goes back and forth and it gradually moves toward less coding and more testing as you go.

That’s my technique. I respect that some people are big advocates of test-driven development, where you start with the tests. Write tests that you know are going to fail because obviously you haven’t written any code yet and say, “This function needs to return the following.” Well, it doesn’t because I can’t even call it. The function doesn’t exist.

Now you go back into your code, implement that function and then you go back and forth. You write your test first and then fill it in, write the code until the test passes. That takes a lot of discipline.

Max: Oh, agreed. This may seem like a benign question, but I’m curious: what do you write your tests–programming language-wise–in?

Bill: Whatever is the accompanying technology for the language I’m using. I’ve programmed in a lot of different languages. SI will use the appropriate testing framework for that language. If I’m programming in PHP, I’ll use PHPUnit. If I’m programming in Java, I’ll use JUnit or one of the other frameworks for testing in Java. Every language, every environment that you use, there will be some preferred testing tool that sort of integrates well with it.

It’s nice to do because if your head is in one language at a time. If you’re programming in Python or you’re programming in Java, you’re thinking in that syntax and with those functions. You know how to do string manipulation, you know how to do other types of operations within that language and it’s just convenient to be able to keep your head in that one place and write your tests in the same language that you are writing your code in.

Max: I realize this might be a more complex topic than most beginners might deal with in writing tests.When it comes to mocking code for testing purposes, is there a particular language that you’ve found it easier for, or that you prefer when it comes to writing more complicated types of tests that require mocking interactions with external tools, for example, a database?

Bill: The experience I had doing database testing, I didn’t mock anything. I tested real databases. The experience that comes to mind is, I was working on a product called the Zend framework for PHP, around 2007 and I wanted to write unit tests to make sure that all the database library functions would work correctly.I could do some stuff in memory with just unit tests and I could do some stuff against an in-memory database because something like SQLite was an embedded database that was fast. It would run in memory and you could do that.

If you needed to test how these database functions would work against our real server, there’s kind of no way you can mock that because you’re testing how it’s going to react from the server’s perspective. The server has its own idea about how it’s going to parse SQL,how it’s going to perform\ and errors it’s going to send back. If you try to mock that much detail, you’re essentially reinventing the database system that you’re trying to use, why not just test on a live server?

I designed the unit testing framework for Zend framework so that it would optionally connect to a live database. You could run the test suite under its default mode to do everything in memory but then you could also enable certain live databases. I was testing MySQL, Postgres, Oracle, Microsoft SQL Server, IBM Db2 and finally SQLite.

Max: Man, that is the gamut.

Bill: It covers pretty much 95 percent of the popular databases out there. That was the goal of that particular project which was to write one PHP component library that could talk to any backend database and try to treat them as close as they could. Once you’ve done a project like that, you realize how much difference there is between all those different brands of database. Although they’re meant to all implement SQL the same, they in practice don’t.

Max: I think one interesting factoid for our audience members that may not have learned SQL yet is, I was surprised to find this out but SQLite is in virtually every smartphone, whether iPhone or Android.

Bill: Yeah.

Max: I think it ships with both.

Bill: SQLite is an amazing product for a couple of different reasons. One is that it’s so pervasive. It’s in all these mobile devices, it’s in Internet of Things devices. It’s probably in your wifi router, it’s everywhere. The other interesting thing is going back to sort of complementary skills you can get to learn that aren’t just simply coding. I have an interest in software licenses, the issues of copyrights, GPL,open source and all those things.

What makes SQLite interesting from that perspective is, it is free. It is public domain which is quite a different thing from simply open source. It means SQLite has no copyright associated with it. You don’t even have to license it from anybody.t’s maybe a subtle distinction for people who don’t follow licensing discussions but it’s a remarkable example of truly free software.

Max: I think I’ve heard that it’s also used in airplanes? I may be mistaken about that.

Bill: I wouldn’t doubt it. The number of places that it’s used is probably hard to track because it’s free. Anybody can download it and use it, they don’t have to sign up, they don’t have to get a license, nothing like that. It’s very difficult to know exactly how far it has spread.

Max: Most all of our audience members, when you walk around with it in your pocket, with your phone in your pocket, you’re walking around with an SQL database.

Bill: Oh, of course. SQL every day, everywhere.

Max: One of the topics that would be an awesome perspective-builder for a lot of people is, you mentioned your career as you experienced it through the early 2000s dotcom bubble bursting and I was wondering if you could share with our audience what that experience was like.

Bill: Oh, being in the dotcom bubble? Yeah, that era was kind of brief. It was 1999 through 2002 and it was the era when there was a few companies, very famous companies like Red Hat Linux and a few others that started up and did an IPO. They have amazing valuations through their IPO and then suddenly everybody wanted to do the same thing.

There were a lot of kind of dumb ideas that came about and somehow got funding, then lasted for a very brief amount of time, and went away. Why did they go away? Because they didn’t have a sustainable business plan.

Being in the software field is not just about technology, it’s about making a product and a business that you can sustain and will make money beyond your initial valuation. If you want to have any stick-to-it-iveness. A lot of those early dotcoms were not sustainable.

Max: What were the jobs you held through that short era?

Bill: Principally, I worked for one company which fancy websites for those other dotcoms. Some company would get a few million dollars and they would say, “Let’s spend all of this and make a interesting site.”

Then they would hire us to put their site together and we would put a site together for an astonishingly large amount of money, some of these because we had a lot of Java engineers who were doing this and put it all together and we might be doing bids for half a million dollars to a million dollars just to create the website.

Of course, those other dotcoms were doing other things with the rest of their money but you can see how when they’re spending that amount of money, it’s probably not a good business investment.

I remember reading a newspaper article at that time about a fellow who was in the newspaper because he was selling his business. It was just some sort of service business like roofing supplies or something. He was getting to be retirement agehe was selling his business and he sold it for three million dollars or something. It was all his. He had not ever taken any investor money and what he sold it for didn’t go 99 percent to his investors, it was all for him for his retirement years.

The journalist said, “How did you do this?” And he said, “I grew the business very gradually over many, many years. I did not buy thousand-dollar chairs. I did not spend money like water. I grew it very gradually in a sustainable way. I added more employees very gradually as the business could support them and it got to this point where I’m ready to retire.”

The thing about the dotcom era is, everybody wanted to do this, get to the multimillion-dollar business overnight without having to invest those years of growth and organic, sustainable business development to try to create it. That’s, it’s very volatile. Some companies succeeded, most did not.

Max: Did the one you worked for succeed?

Bill: Ultimately, it did not. We were dependent on getting hired by other companies who were all in this sort of dotcom mode. When they went away, when the dotcom crash happened, which is essentially when the investors realized, “Hey, this isn’t panning out, let’s stop investing into these silly ideas,” then all the people who were the ones who would hire us, they all disappeared, and very quickly, we disappeared, too.

Max: What was that last day like?

Bill: The last day was interesting. The employees at that business were expecting the company to run out of money, our employer and we knew that we didn’t have many clients giving us revenue. We knew that we were essentially burning through our residual money. In that environment, when we got an email saying, “Everybody come to the conference room, there’s a big meeting,” I realized, and everybody around me realized, that was it. This is the last day and no hard feelings, it was a great run, but this is the end.

I was at my workstation writing some code and I literally just stood up from my workstation. I didn’t even save the code that I was working on because I realized I wasn’t going to come back to that computer again and whatever I was working on would never see the light of day.I grabbed my backpack and I went to the meeting, and we got laid off.

Max: How do you bounce back from that? I know the answer to this question but I want our audience to hear the good ending.

Bill: What I did after that is, I contacted one of the businesses that I had done some work for through that employer through that professional services employer. They still had a need for somebody to do work for them and I no longer had any reason to restrict myself. There was no non-compete clause with my former employer because they were shut down.

I said, “Hey, would you like me to work for you? I’ll charge you half as much as you were paying the professional services company.” I still get more money in my pocket as a result by cutting out the middleman of this managing company. They were very happy about that and that lasted for about two and a half years.

Max: On your behalf, I would like to plug a couple of things, if you don’t mind.

Bill: Yeah, absolutely. I’m all in favor of that.

Max: Well, we should mention that Square is most definitely hiring, if you’d like to work with Bill, you guys should check out Square’s jobs, particularly anything database related. The other thing I wanted to plug on your behalf is that you’re an author, I thought it would be nice to plug your book, “SQL Anti-Patterns: Avoiding the Pitfalls of Database Programming.”

Bill: Yeah, I wrote that a few years ago. As we mentioned, I answer a lot of questions online. I’ve been doing that for so many years that I started seeing some of the struggles and the problems that software developers have come up over and over again. The same questions come up, I wanted to write a book and kind of collect the most common ones and then write a well-written and fully-featured description of what the solution is for some of those things.

The way I presented that is to show, here’s the blunders that I see people making over and over again, particularly in SQL and database programming. The most common types of blunders and how you should fix it. How you should do things in a different way, and how you should understand databases, to understand enough not to paint yourself into a corner.

Max: One thing we’ll do for certain is include links to Square jobs and also the book in our show notes.

Bill: Yeah, absolutely. Thank you very much.

Max: Bill, this has been awesome. Thanks for coming on.

Bill: I’m really pleased. Good luck with your podcast.