So, you’ve read the introduction to the Carbon Five Guide to User Research and you’re ready to get started. Welcome!
During this step we’ll be working through what we’re hoping to find, who we’re hoping to talk to, and what we’re hoping to ask. If you’re trying to convince someone else in your company to invest in a research project identifying the basic assumptions and outcomes like this is a great place to start.
We’ll be using the hypothetical company Delivery Healthy. Delivery Healthy is a startup that serves people who are trying to eat healthy while still ordering a lot of take-out, because they say you should write what you know.
Ready? Let’s go!
User Research focuses on understanding user behaviors, needs, and motivations through observation techniques, task analysis, and other feedback methodologies.
User research helps us understand the constraints and opportunities of the audience we’re building for, and is a core part of building a successful product.
Let’s say you’ve got a great idea for a product. Will your users agree? How do you reach them? In order for your product to succeed, it needs product/market fit.
Defining the users you want to reach and talking to them before you build will will give you empathy and a clearer sense what your users hope to achieve using your product. It’s much easier and more effective to design with a specific person fixed in mind than a set of demographics without a distinct voice.
One month ago I was on a panel at Grace Hopper, “Startups, Big Companies, Silicon Valley, Government Contractor — What’s the right career path for you?”. I was speaking mostly to software engineers who were just entering their career post-college or transitioning from their first job. I was on the panel with four other talented software engineers from a range of job experiences, Sha-Mayn Teh (Teachers Pay Teachers), Jennifer Liu (Quizlet), Neena Parikh (Benchling), and Stephanie deWet (Pinterest). Here are some of the thoughts I personally shared with the room on how to decide on what kind of company to work for.
Working on an oldish Rails project, I came across some smelly ActiveRecord code that begged for some refactoring love. I also spent some time speeding up pages with slow/many database calls. Between those two experiences, I felt the inspiration to write-up some “Back to Basics” Rails Database Best Practices.
Databases are extremely feature rich and are really freakin fast when used properly. They’re great at filtering and sorting… and many other things. If the database can do it, it will do it way faster than doing the same thing in Ruby, or any other language for that matter.
You might have to learn a little bit about how DBs work, but honestly, you don’t have to go very deep to reap a majority of the benefits.
We generally use Postgres. What you choose is less important than getting to know it and using its features to make your product awesome. If you’re curious about Postgres, there are some good resources at the end of this post. We love it.
Our first, overarching rule: Let your database do what databases are good at, instead of doing it in Ruby.
Monolithic applications are great when you start building your company, but as time progresses, they become difficult to maintain. These codebases, as they grow, easily become Big Balls of Mud.
When building large applications in frameworks like Rails, the very convention-over-configuration design principles that made Rails such a joy to use begin to get in the way when the application grows in scope. You may be experiencing the same pains as well if:
Another month, another talk night in Santa Monica! This month’s talks on October 19th cover the softer skills of a professional’s life such participating in conferences and running processes before they run into the ground.
First, we are happy to have engineer and advocate Carina Zona! She’s in town to speak at the SCNA conference on Oct 21st at USC, but if you can’t make it there we’re hosting her at the westside. As the founder of CallbackWoman, expanding diversity of all underrepresented genders as speakers at conferences, she’ll be speaking “On Proposing Your First Conference Talk”:
Giving conference talks is a game changer. Speaking can propel a career forward, expand your network considerably, and lead to wonderfully surprising opportunities. Come learn about how to get started, and get some practical skills for doing your first proposal how to find relevant opportunities, dissecting Calls For Proposals, evaluating their for fit with you, questions it’s cool to ask organizers, the darned fair expectations to hold, brainstorming a topic, and writing abstracts!
Then Carbon Five’s Ryan Finley will be shining a light on the cold heart truth; some projects ARE doomed from the start. Ryan explains why and how to tackle the causes in “Ch-Ch-Changes: Setting the Foundation for Successful Process Change”:
Key decisions made, or not made, before the outset of an initiative can either give your team the opportunity to succeed or set them on a path to failure. We will discuss the things that can be done prior to kicking off a change initiative to give it the best shot at success, and some strategies to deal with the issues that may arise when this upfront work hasn’t been done.
Doors open at 6pm. Talks begin at 7pm and includes Q&A. The rest of the evening, until we shut down at 9pm, is free time. We also have an accompanying Slack to discuss during and around the event; contact a group admin to get an invite.
So sign up on Meetup and we will provide pizza and drinks (beer and non-alcoholic drinks), wi-fi, cool vibes and killer talks.
I want to discuss a topic near to my heart, a topic I believe to be the crux of effective software design. No, it’s not a new functional language, it’s not a fancy new framework, it’s not a how-to guide to do micro-services, nor a quantum leap in the field of machine learning.
It’s much simpler. It’s about names.
Names define us. They give life to abstract ideas and concepts and yet also stand in for real, physical objects. They’re language concepts, but more than that, they’re units of meaning. When used precisely, names enable shared understanding and smooth teamwork among people. Continue reading …
If you’ve spent anytime writing software, you’ve used an open source project. Open source projects save you time and energy by leveraging other people’s experience and hard work, leaving you free to focus on the core features of your project. Often people want to contribute to these projects, but don’t know where to start. They are afraid their contributions will be ignored or, worse yet, attacked. With tools like GitHub freely available for open source projects, anyone can become a contributor. If you follow a few simple steps, you can have a positive experience. Continue reading …