On a recent "Developer on Fire" podcast with Dave Rael, I was caught a bit off guard with the question: "Provide three tips for delivering more value". That was it. It was left completely open as to what it meant.
First off, clearly you should listen to the whole podcast for the most value! 😂 Failing that, I thought I'd write up my answers here, to let you gauge how I did.
1. Know who your user is
If you've been following my writing, you won't be surprised by this answer. It's something I've been harping on a lot lately. The user isn't some person banging on a keyboard, it's the person taking the train, or trying to organize a party on the weekend.
Users exist in the real world. They're actual people, not mindless consumers nor button pressing automatons. The software you right is only a tool to them.
Learning to understand who your users are, will give you a huge value advantage in your programming career.
2. Take care of yourself
It's easy to say, but harder to follow through on. I've unfortunately seen what happens when people neglect themselves. I've seen frustration, tension, and burnout. You'll suffer, the company will suffer, and the product will suffer.
You are the foundation of the work you do. Your work will deteriorate as you yourself start to slip.
Taking care of yourself is an absolute requirement to putting out quality work. If you're interested in taking the first step, read my article on easy programmer fitness over at Simple Programmer.
3. Just try it
You won't know if you're good at something, or whether you like something, until you try it.
For example, I have no idea how to promote a book, but I wouldn't of known that if I didn't have a book to promote. It's forcing me to learn new things, and giving me new experiences.
Try new things, in your career, out of your career. Go out and try it. Who cares if there are other people doing it better -- that's always going to be the case. Just try the things you like and want to experiment on.
Trying is the path to learning.
What do you do to add value?
Let me know what you think of my answers and share with us your own tips for delivering more value.
Image by Free-Photos from Pixabay
Oldest comments (6)
I couldn't agree more. Actually, I could. In the ideal world I don't just want to know who my user is - I want to talk to them, every day, and say "Hey, user - this thing I did for you - whaddaya think?".
Often this conversation is given to another "role" - a 'business analyst' or 'product owner'. Or worse the conversation is avoided entirely and you're left trying to interpret analytics data to work out what the user thinks.
By far the greatest satisfaction I've ever had as a developer has been when the actual people who use what I've written say to me "that's good", or - better - "that's not good, can we do it like this instead?", or best - "I've got this crazy idea, can we try it?"
Yeah! If you like fast feedback loops and maximizing value, get to the coal face and talk to the workers. Get yourself into the world and get dirty!
Sounds like a great episode, queued!
One small thing that you can do that adds up is be approachable.
I don't have a lot of seniority in my current role, yet I regularly have people throughout my department come to me for help ranging from technical rabbit holes to best practices for random business needs.
By broadcasting that you are willing to help and actually help when they come to you, you will have a lot of opportunities to add value. If you are approached with something you don't know, follow them to the answer and you will learn one more thing that others around you didn't know.
hi!
I agree with your points.
I would add this (it's probably a subset/related to "know your user"):
-know the process
after having known your user I think you should get insights of the process/topic/environment where the software will be used. at the end the values you give are there (better performance, features...ease)
do you agree?
Yes, I'd include that in knowing your user. It's no limited to knowing who they are, but what they are doing. That's your process, and it's also required knowledge.
yeah!
thanks for sharing