100x Software Engineering is when you build something someone actually uses.
If a Startup is practicing user-centered Design, they might realize that a helpful way to make actual progress is to start with the pain of users and work back from there.
Your job as a Software Engineer is to anticipate that this chaos will happen, and be ready for it - because a measure of code quality includes how easy the code is to change.
Design Twice, Code Once
Defining User Pain: This could be pain they experience using your software, or pain they experience in the world that software could solve. This definition is a little broader than the typical 'Pain Points' users experience with just your software.
Users...
- Experience pain.
- Appreciate solved pain enough to use apps or software.
- Are not you, so it can be really inaccurate to say you understand their pain (even if you have experienced it yourself).
- Experience barriers you won't know about until you explore. It is cheaper to explore with a picture on a napkin, than with code.
- May not understand the pain, until you present a solution that takes the pain away.
- Are less likely to use something that doesn't solve some kind of pain. They prefer solved pain over fanciness.
Design: Research Study 1 - Passwords Manager
Having to remember many passwords for many sites and apps is painful. A study shows that the average person has 100 passwords. Sounds painful.
Design: Research Study 2 - So many Leaked Passwords
Did you know that over 6 billion credentials were leaked in 2021 (i.e. both username & password)? Even more painful! This means that users can't rely on password protection alone anymore (free cybersecurity tip there).
Design: Speaking to Users
There are many ways to interact with users, so for the sake of simplicity assume that you created a neat fat marker sketch or wireframe and deployed it as a clickable Figma prototype.
This sketch described 'logging in' once with username, password, and multi-factor authentication. Then they were allowed to 'log in' to a bunch of fictitious apps by simply clicking a single button on said apps front page.
What do you think you would hear? How might that impact the design of the software?
Design: Build a Hypothesis
All of this helps to build a falsifiable Hypothesis:
"We believe that Single sign-on (SSO) solves our users pain by allowing users to login once, and access multiple applications. We believe it is secure because it utilizes multifactor authentication that does not rely entirely on potentially compromised passwords."
Check out Tal Ravivs post on Hypothesis if you are interested in a deeper dive with some fun visual examples.
Engineering: How does Code Quality fit in?
Think about how you would build a set of code quality principles.
- How can you use design patterns, abstractions, and interfaces to respond quickly to changes in requirements?
- How do you acquire the metrics to prove or disprove hypothesis?
- How do you push back when requirements seem too vague, or the underlying design is unfinished?
- Feel free to discuss this list in the comments below!
Conclusion
I hope this quick dive into some components of Design helps you as an Engineer or a Technical founder understand why it is so important, and why you might get that unsettling feeling once in a while that you are building something wonky.
A great mentor in the Design space I've found that has been accessible to me as an Engineer is Joe Natoli (check him out!)
I don't claim to be an expert Designer, just trying to connect Engineering & Design here as I grow - and always open to constructive feedback on this stuff. : )
Sage's Bookshelf
This is the grab bag of cool things.
- There is No Silver Bullet - Thanks for sharing Conrad Manske!
- AI: Efficient streaming language models with attention sinks - Thanks for sharing Ryan Walden!
- Legal: It is now a legal requirement for your Software to be Accessible, and you can be Sued (I'm not a lawyer, and this ain't legal advice, just thought it is important for all Software Engineers to know and save their company a lot of money)
- AI: There's a State of AI Report from Air Street Capital (I learned that Generative AI visual effects have already made their way into a Netflix production)
- AI: LLM's Can't Reason, According to Apple (Some folks need to hear this: current LLMs are sophisticated pattern matchers that are fragile)
- Prototyping: A fun dive into Valves 25 Prototypes for the Steam Deck (Even Valve needed 25 prototypes to get it right)
- Social Media: Don't build your castle in someone else's Kingdom (Makes sense to me, building a castle helps me learn too)
- Leadership: People can read their Managers Mind (A blunt acknowledgement of leadership blind spots)
- Software Engineering: Hypothesis-driven Development (I really resonated with this one, and I discovered some great articles from Tal Raviv through this article)
- Tool: Obsidian: Note Taking - Thanks for sharing Andrew Ingalls
Feel free to leave me feedback in the comments, suggest a change, or share your own really cool thing! Your link could show up in the bookshelf, and I'll credit you as an honorary bookshelf contributor. š
Interested in help building Software? Check out Rosenblatt AI via Website, or check out the Upwork.
#startup #cto #fullstack