Stats for nerds
2recommend
8mentions
6people
2008–2025years
38% recommend63% neutral
Mentions per year
What Hacker News says
- There are three main subproblems to your questions:
1. Find out what users wants. The answer to that is research and the only book I have is Just Enough Research by Erika Hall. I also found Essentials of Business Research Methods by Joe Hair Jr. et al.
2. Build the thing that the user wants. That's mostly the real of Software Requirements and I have two candidates for you:
- Mastering the Requirements Process: Getting Requirements Right by Suzanne and James Robertson
- Software Requirements by Karl Wiegers and Joy Beatty.
3. Build something that the user likes and that he can use. That's UX and I have three candidates this time:
- Observing the User Experience, 2nd Edition by E. Goodman and M. Kunlavsky
- Understanding Your Users, 2nd Edition by K. Baxter et al.
- The UX Book by R. Hartson and P. S. Pyla
All of those just emphasize having an objective view of what you want to bring to the users and a rational execution strategy. I haven't read all so I can't judge them, but I believe they will give you enough starting points for you to devise your own method.
- Amen to that. I'm gonna rant a bit about my experience, strategy, and opinions on the cult of bad managers.
The cult of talentless MBAs, man. Took something as well meaning as XP/Agile and turned it into a way to formalize having no plan and offloading it to developers then bitching when the result isn't what they had in mind. Actually though they never really had anything in mind, they just thought they did and someone told them this method is a great way to get results after you poorly explain a hunch you have based on some crap that you saw some other company is doing.
Meetings should never be more than an hour, anyone who doesn't want to be there should be allowed to leave whenever they want. If they are required to present something then they should be allowed to show up just for that if they think that's a better use of their time. The person booking it should send an itinerary with the meeting and outline what will be discussed in 5, 10, 15 minute blocks. If anything goes more than a couple minutes over, that means the person who put the meeting together didn't understand the scope and it needs to be addressed again later and move on. Meetings are not the time to ideate at hostages. The end of the meeting should have 15 minutes for general discussion that anyone can skip. But this is critical to always block for because we all work remotely and if you don't make this a habit, problems brew because all interaction becomes transactional. The more people that are required to be in a meeting, the shorter it should be and likely the less useful it was ever going to be. If the meeting is just broadcast and not a dialog, then go make a wiki page, screencast, or just send everyone a voice memo and pretend like you did a good meeting.
This is my recipe for meetings that I've developed over 20 years of software development in the trenches as well as product management and working as CTO in a couple startups. I believe in these principles so much that I'd be happy if it was carved in my tombstone. The thing that tanks projects is trust between collaborators and people cargo culting what it means to be a manager. Meetings without care destroy trust. Also, the job of a manager isn't to be a puppet master, it is to talk to the people you are working with about what interests them the most and find the tasks that best fit their interests. Create pipelines for communication that work with all stakeholders so people can easily communicate the need to spend extra time on something hard or just walk away from something that doesn't work for them. As a manager I see my job as being the janitor. I sweep the floors. I clean up hard coded environment variables. I run and rerun and rerun the stack and look for kruft and inefficiencies, I do a repetitive meditation on removing frustrations and packaging work tools so anyone who wants to do anything with the code base can easily touch and manipulate any part of it with very little effort completely on their own computer.
I have only worked with a couple managers that sort of do parts of the things I'm saying up here. As I started codifying and applying the above rules I started to be able to not only turn projects around but overdeliver in less time with happier people.
EDIT: Also, shout out to Karl Wiegers Software Development 3rd Edition[0] and it's companion book Visual Models for Software Requirements[1]. Those books coupled with really learning to ask about peoples interests and needs and listen to not just what they are saying but watching to see if they are engaged changed my life and I think I've made more than a few working experiences better for everyone involved and I hope that's something I'm remembered for.
Also Marshall Rosenberg's Nonviolent Communication[2]. As a sarcastic pedant person on the autistic spectrum, finding his audio book on NVC helped me be a better listener and problem solver and not create unnecessary problems just by using my words in dumb and glib ways in the wrong setting. I mean, I still do that, but now I'm aware when it's unhelpful and do it much less.
[0] https://www.amazon.com/Software-Requirements-Developer-Best-...
[1] https://www.amazon.com/Visual-Software-Requirements-Develope...
- Selling alone can get me a couple years worth of runway but I've been in two where overselling before ops/process where at a stable velocity everything choked so bad it forced the biz to pivot (not in a fun or good way).
What OP is calling a "product engineer" is a good perspective for people that don't quite get that we live in a cash ecosystem and love to write good code but a lot of people hired as product engineers haven't written any code in decades. Hiring for that title is as clear as mud. Even if I have one that'll make my day in my company I might still need a senior dev that understands this stuff but wouldn't bother calling himself a "product engineer" for fear of getting crushed by the wheel of chasing customer expectations without qualifying them.
At the end of the day no matter what decisions the "product" team makes, as the "software developer" I need to make things happen and that takes leading the narrative enough that I don't get hung out to dry. Engineering predictability and its communication is the key to all success. Something that has helped me wildly has been the Microsoft book Software Requirements (3rd Ed) [0]. The system it lays out for planning, analysis, and risk mitigation is something everyone should read if they want to be more effective. It doesn't even have to be applied dogmatically.
If I can respond with a common lexicon of a vision and scope with a well laid out requirements spec then there isn't an issue with product, c suite, and dev communicating and everyone making money. It still shocks me every time I'm in a new org how hard that is to pull off even with the instructions. If comms and velocity track then there's enough wind to fill the sales sails.
- “If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project.”—Karl Wiegers, Ten Cosmic Truths About Software Requirements
Every word Karl writes is gold. That man knows more about Requirements Engineering than anyone and has made a career of helping Requirements Engineers become better.
- My top priority books:
The best books I've ever read:Software Requirements - Karl Wiegers Programming TypeScript - Boris Cherny Associate Cloud Engineer Study - Dan Sullivan Design Patterns - Gang of Four Refactoring - Kent Beck, Martin Fowler Programming Pearls - Jon Bentley Patterns of Enterprise Application Architecture - Martin Fowler The Pragmatic Programmer - David Thomas, Andrew Hunt CSS: The Definitive Guide - Eric A. Meyer, Estelle Weyl Working Effectively with Legacy Code - Michael Feathers Head First Design Patterns - Eric Freeman, Bert Bates Code Complete - Steve McConnell Peopleware - Tim Lister, Tom DeMarco Clean Code - Robert C. Martin The Clean Coder - Robert C. Martin Clean Architecture - Robert C. Martin Don't Make Me Think - Steve Krug Functional Design Patterns for Express.js - Jonathan Lee Martin The Surrender Experiment - Michael A. SingerPrinciples - Ray Dalio The Power of Now - Eckhart Tolle The Effective Executive - Peter F. Drucker Think and Grow Rich - Napoleon Hill Extreme Ownership - Jocko Willink, Leif Babin Influence - Robert B. Cialdini The Startup Way - Eric Ries The Lean Startup - Eric Ries 12 Rules for Life - Jordan B. Peterson Measure What Matters - John Doerr, Larry Page The Fish That Ate the Whale - Rich Cohen The E-Myth Revisited - Michael E. Gerber The Score Takes Care of Itself - Bill Walsh, Steve Jamison, Craig Walsh Management - Peter F. Drucker Thinking in Systems - Donella H. Meadows Blue Ocean Strategy - W. Chan Kim, Renee Mauborgne - Thanks for posting this! It's a nice breakdown! I've been working on some ways of visualizing our container systems, networks, roles, dependencies, and you know ... the whole ball of wax. It's for a specific app, but I'm going macro level.
I found Karl Wiegers Software Requirements about eight years ago and have been evolving a high level model based off his visual model superset of UML and I've found it not quite to cover the complete roles of the container process. You've helped me bucket some fuzzy black boxes with your colored boxes!
Something I've been chewing on at the middle level of visualizing container roles is not just the role blend you specify here but now the overlap of networks, container technology, federation, and similarity from development, to release staging/production, to customer bare metal deploys, to legacy CI then staggering that over AWS, GKE, my personal OSX machine, my new Linux machine, the rest of my teams OSX machines.
We are a small company that is on the bleeding edge of cloud GPU stuff, we have a code base with some legacy warts that we are growing out of and channels that need to be distributed through them. The containerized GPU ecosystem is growing FAST! OSX is not really going to support nvidia-docker any time soon because of xhyve. The fuzziness of containers just being one thing adds to so much operational confusion! To do a lot of things sometimes the systems and roles you're using containers for can feel like "Who's on first?"
To be clear, I'm aware that I'm over thinking what follows, I think it's interesting and most of it is just built out of a sense of play. I'm still just playing with the concepts as they relate to cluster operations. No models I've used from before quite cover the relationships at a glance that we now have while using containers. Especially to people who are just getting into them it can feel majorly overwhelming because at first they just see them as VMs. I really like your banding for the contexts. I'm totally going to work this into the ops flow.
Anyway here's a whacky thing I'm dreaming up, I started by thinking about the system similarities in buckets that I made into hexes, I put color sections on the hexes for overlap. AWS, GKE, and OSX would be hex tokens. Route53, GoogleDNS, Consul/Dnsmasq would be lets say their yellow corners. Some system deployments rely on different parts so you can look at a key, but I can corner label a green, orange, purple set of hexes then just light up the matching overlap. So like I'm doing a pretty standard UML layout but I can throw some Star Trek style pips on the container and at a glance you can know what it touches. I just got out of the system wide sketch phase with this and I'm really digging it.
I've also been doing experiments[1] with procedural color[2] and shade so instead of picking items at random a base can be picked then branches from it are mathematical so you can infer context, state, or connection even if you have to shift pallet because you've drilled down into a subsystem.
A bit over a year ago I came up with this system relationship flow that I'm calling "The Lotus"[3]. It came from looking at the hexes and trying to put them in appropriately adjacent context then realizing the system "joins" sort of fan over each other and end up making a lotus thing pattern. This spawned from being asked to outline a VERY complex font matching system in a way that was "not technical" it started out as tongue in cheek and still is pretty weird, but inside these experiments I'm starting to see some patterns grow that I really like. Especially as it relates to containers.
This all feels like a massive rambly overshare, but I really liked how you put it together and I thought I would share some of the weird stuff I'm thinking about.
Thanks again!
[1] https://github.com/millerhooks/GraphTerm
[2] http://devmag.org.za/2012/07/29/how-to-choose-colours-proced...
[3] https://github.com/millerhooks/SystemVisualizationConcepts/b...
Related
Mastering the requirements process
2 recommend · 2
Modern Software Engineering
3 recommend · 8
Designing Data-Intensive Applications
457 recommend · 846
Software requirements & specifications
2 recommend · 4
2011–2026
Software Foundations
58 recommend · 77
The architecture of open source applications
204 recommend · 257
