psql is a CLI editor that ships with Postgres. It’s incredibly powerful for working with Postgres, and doesn’t take too much of a learning curve to start to get comfortable so you can really feel like an expert working with your database.
Just a rundown of a few things to get you started:
I’m often asked what do I think the future for Postgres holds, and my answer has been mostly the same for probably 8 years now, maybe even longer. You see for Postgres itself stability and reliability is core. So where does the new stuff come from if it’s not in the stable core… extensions.
Extensions within Postgres are unlike most other databases allowing you to modify or well extend the standard Postgres behavior. You can build other storage backends, new types, etc. Postgres itself ships with a number of extensions within the “contrib”. The list of contrib extensions hasn’t changed any time recently, but even contrib is a small sampling of what is possible. Beyond core there is a whole world of extensions, I want dig into just a smalls sampling starting with a few in core…
If you want to seem like the smartest person in the room, wait for a break in conversation, after sitting quiet for 15 minutes, and ask “What problem are we trying to solve here?” It works every time.
What do I mean by trick/hack? This can be super flexible, but I’ll toss out a few of my own personal ones.
One of the rules of my product management philosophy, is if you’re going to use a tool or trick then use it often. This is in fact one of my favorite interview questions for PMs. If you ever interview with me, be prepared it’s coming. It applies for engineering managers and others in leadership roles as well, but I’ve found especially get for PMs.
7 years ago I left Heroku. Heroku has had a lot of discussion over the past weeks about its demise, whether it was a success or failure, and the current state. Much of this was prompted by the recent, and on-going security incident, but as others have pointed out the product has been frozen in time for some years now.
I’m not here to rehash the many debates of what is the next Heroku, or whether it was a success or failure, or how it could have been different. Heroku is still a gold standard of developer experience and often used in pitches as Heroku for X. There were many that tried to imitate Heroku for years and failed. Heroku generates sizable revenue to this day. Without Heroku we’d all be in a worse place from a developer experience perspective.
But I don’t want to talk about Heroku the PaaS. Instead I want share a little of my story and some of the story of Heroku Postgres (DoD - Department of Data as we were internally known). I was at Heroku in a lot of product roles over the course of 5 yrs, but most of my time was with that DoD team. When I left Heroku it was a team of about 8 engineers running and managing over 1.5m Postgres databases–a one in a million problem was once a week, we engineered a system that allowed us to scale without requiring a 50 person ops team just for databases
This will be a bit of a personal journey, but also hopefully give some insights into what the vision was and hopefully a bit of what possibilities are for Postgres services in the future.
Was having a conversation with a founder earlier today and the topic of hiring functional leaders came up. I offered one of my common pieces of advice which was don’t hold the reins too tightly once you hire them. It’s something I see happen over and over to first time founders. You hire a new VP of Product and then still continue to oversee so much of the product process yourself. It is understandable, it’s your baby, you’ve spent years building it to this point, they don’t love it the same way you do.
A few months ago there was a tweet from @jasoncwarner about leadership skills/super powers:
I’ve spent quite a bit of time in product management roles, and in recent years more in leadership. I’ve found a lot of the skills in product to translate into good leadership skills as well, but maybe I’m bluring the lines there. Regardless, with his 5 skills I found myself nodding and have written about each of these some on my blog and then at times on twitter. He long since deleted the tweet, and while I wait for him to republish I thought I’d reprise a few of these with my own view point.
At past jobs I’d estimate we had 100 different production apps that in some way were powering key production systems. Sure some were backend/internal apps while others key production apps such as the dashboard itself. At other companies we had a smaller handful of Heroku apps that powered our cloud service, about 5-10 in total. Even just working with those internal apps it’s a number of things to keep context on. But when it comes to interacting with something you don’t know getting a lay of the land quickly is key. In helping a customer optimize and tune, or even just understand what is going on in their app an understanding of the data model is key.
As I just started a few months back at Crunchy Data I found myself digging into a lot of new systems and quickly trying to ramp up and get a feel for them.
One of my most fascinating work experiences was going through the spokesperson certification process at a large tech co. This isn’t some rubber stamp virtual training to not use profanity on stage type training. This is the training they would give to any executive before you were greenlit to talk to press. When I say press I mean Techcrunch, but also Bloomberg, or Jim Cramer, or any major big brand news outlet.
As a product manager over a specific product line I knew my product well. Put me in front of an unhappy customer and I could lay out our roadmap, listen to their questions, take product input, and get them to a happy place. But this wasn’t about my product (only). A person with the spokesperson stamp could be asked any question about an entirely other area fo the company. You had to know every recent product launch, all the key metrics, know where traps may lie, and you had to land the core company messages in addition to the ones you cared about. To study you received about 100 pages of a powerpoint presentation that had key releases from each product, key numbers, customer stories.
I think back to my time in college, and I learned some valuable things. I also learned some incredibly worthless things (i.e. don’t flip a car upside down and then backover… it’ll break the axle so you can’t roll it). Even in classes… the basic approach to a supply/demand curve to maximize profit is cute when done in a classroom vs. the complexities of how things actually work… I mean I get the idea behind it, but what you learn is so far being able to be translated into being usable. But what surprises me looking back was a couple of skills around running meetings that I find so rare in the workplace that have immense value.
I’ve always been fascinated at the intersection of business and technology. I’d been coding for a long time before college, and while interesting it was also a means to an end. When you combine technology with business you can solve things in entirely new and valuable ways. My major was management information systems, and all folks in my program came out with a computer science minor in addition to their business degree–something pretty rare for more MIS majors in other programs and well generally for anyone coming out of a business school. Perhaps I’ll get into the value of CS training even if you aren’t looking for a CS job some other time.
Within the program we would have a senior project that was actually a real world project for one of the large companies that sponsored part of the program. We’d have monthly reviews with the company stake holder. We’d also have weekly meetings, these were especially well run. There were really 3 items that made them especially efficient.
