Find Help Online Mindfully — and Effectively!
Here’s a situation that might sound familiar: you’re in the middle of a project, and you realize you’re tackling a problem you haven’t seen before. Perhaps your search function query is returning too many results, which is slowing down your website. You figure you shouldn’t display the data all at once, and you’ve heard about…
Max Pekarsky
Software Engineer
Here’s a situation that might sound familiar: you’re in the middle of a project, and you realize you’re tackling a problem you haven’t seen before. Perhaps your search function query is returning too many results, which is slowing down your website. You figure you shouldn’t display the data all at once, and you’ve heard about something called “pagination,” which sounds close enough. So, you quickly look through the codebase for similar examples, and then google “pagination” + “[your stack]”. An hour later, you have 17 open tabs, a growing headache, and no actual progress on your project. Congrats, you’ve officially gone down the research rabbit hole!
As the sun is starting to come up on a new day, you stumble across some library code that seems relevant, so you copy it over, and it seems to work. You don’t fully understand why, but the code runs and the tests pass. So, you move on, and everything is fine — until a few days later, someone else pushes a change, and everything breaks.
As developers, we’re constantly researching new approaches, processing new information, and selecting the best solutions under deadlines. Having to research isn’t a signal that you don’t know enough — it’s a crucial part of the job. Terry O’Shea, a software engineer at Etsy, says she looks things up “dozens of times a day… I’ve spent more than a few sweaty half-hours phrasing and rephrasing a search query.” Learning to research effectively is a significant part of leveling up as a developer.
The trap many beginners fall into is following a solution that seems close enough. It’s incredibly easy to get lost if you only have a vague sense of what you need. At best, you’ll stumble onto a working solution without really understanding it; at worst, you’ll find yourself frustrated and way off course. I’ve been there myself while working as a software engineer at Bonus.ly and the NYC Mayor’s Office. There is no perfect process, and different approaches work for different people. However, one trick I’ve found to be quite conducive to effective research is to stay mindful through the process.
Step 1: Understand the Landscape
Before you start wading through search results, start by defining your problem in the clearest way you can. Aim to understand, broadly, what the high-level moving pieces are. This may feel tricky at first, but considering how to word your question will help you understand it, remember it, and communicate it to others. James Mayr, a product manager at The Muse, finds it helpful to front-load this process: “I try to do the research long before I get to the actual coding; if I have to look something up during the middle of a coding session, it totally pulls me out of the flow.”
In the earlier example, pagination is just one possible solution to a slow page load. If you take time to explore the underlying problem you’re facing (a large, slow server response), you’ll find other possibilities. You might implement infinite scrolling, refactor your database queries, cache search results, or even redesign your UX so users initially request more specific data. Forming a sense of the landscape will help you narrow in on an appropriate, effective solution rather than chasing a close enough one.
Beware of the XY problem — where, instead of asking for your actual problem, you ask about your best hypothesis, and get an answer to a whole other question. As you research, keep asking yourself: “Does this resource help me do X, the problem I just defined?” It might sound trite, but if the answer is anything like, “Well, it helps me do Z, which helps with Y, which is how I can do X,” you’ve probably gone too far.
Step 2: Be Selective About Resources
You’ll need different resources at different stages of the research process, so be cognizant of the type of resource you’re looking for. For example, if you’re struggling to understand the concept of hashing (a cryptography technique commonly used to obscure sensitive data), reading a tutorial on bcrypt (a popular hashing library) is probably not the best use of your time.
As you search the internet, you’ll find roughly four types of resources:
This may seem like a small change, but constantly evaluating if you’re looking at the right type of resource will force you to be more discerning, and will save you lots of time. It’s easy to get distracted reading a tutorial that sort of makes sense, but remember: your goal isn’t just to get the code working; it’s to write code you can understand and maintain.
Although the internet is full of knowledge, sometimes the most effective way to get an answer at work may be from your colleagues. Esther Leytush, a full-stack developer at Betterment, says her rule of thumb is to “google anything that I can frame as ‘How do I…’ and ask coworkers, technical leads, or managers when the question can only be framed as ‘Should we…?’ Your colleagues are the best resources on domain- and process-specific knowledge, and can often help you get unstuck. “If an obstacle that’s stopped your work for half an hour,” says Etsy’s O’Shea, “definitely take it to a colleague — maybe they’ll know the solution; maybe they’ll just commiserate.”
As you narrow down your choices towards the solution you actually need, you can start looking for specific tutorials or documentation. Now, you can shift from trying to understand the landscape to finding and writing code that solves your problem.
At this stage, make sure you don’t copy over blocks of code without understanding every line. Many tutorials oversimplify the problem for the sake of brevity and clarity, but the sample code they use is often not suitable for production. Copying blocks of code will lead to technical issues when you can’t explain or maintain your work, and ethical issues around plagiarism and intellectual property. Moreover, by taking the time to rewrite and customize the solution now, you’ll find it easier to understand similar problems the next time.
As with everything else in life, you’ll get better at research with practice. You’ll find it easier to reach the right resources using the right words, and the knowledge you gain from mindful research will illuminate areas of programming that used to seem daunting. “I’m more discerning about the solutions I find,” says O’Shea. “Instead of just copying and pasting someone’s hacky CSS, I’ll keep searching until I find the most idiomatic, performant, concise, or elegant way to accomplish what I want.”
So, the next time you run into a scary new problem, don’t immediately reach for Google. Define the problem, identify the resources you’ll need, stay mindful, and remember — this isn’t just how you solve the problem in front of you, it’s how you become a better developer.
Tags: bulletin, coding, mental health, mindfullness, research, software development
As the sun is starting to come up on a new day, you stumble across some library code that seems relevant, so you copy it over, and it seems to work. You don’t fully understand why, but the code runs and the tests pass. So, you move on, and everything is fine — until a few days later, someone else pushes a change, and everything breaks.
As developers, we’re constantly researching new approaches, processing new information, and selecting the best solutions under deadlines. Having to research isn’t a signal that you don’t know enough — it’s a crucial part of the job. Terry O’Shea, a software engineer at Etsy, says she looks things up “dozens of times a day… I’ve spent more than a few sweaty half-hours phrasing and rephrasing a search query.” Learning to research effectively is a significant part of leveling up as a developer.
The trap many beginners fall into is following a solution that seems close enough. It’s incredibly easy to get lost if you only have a vague sense of what you need. At best, you’ll stumble onto a working solution without really understanding it; at worst, you’ll find yourself frustrated and way off course. I’ve been there myself while working as a software engineer at Bonus.ly and the NYC Mayor’s Office. There is no perfect process, and different approaches work for different people. However, one trick I’ve found to be quite conducive to effective research is to stay mindful through the process.
Step 1: Understand the Landscape
Before you start wading through search results, start by defining your problem in the clearest way you can. Aim to understand, broadly, what the high-level moving pieces are. This may feel tricky at first, but considering how to word your question will help you understand it, remember it, and communicate it to others. James Mayr, a product manager at The Muse, finds it helpful to front-load this process: “I try to do the research long before I get to the actual coding; if I have to look something up during the middle of a coding session, it totally pulls me out of the flow.”In the earlier example, pagination is just one possible solution to a slow page load. If you take time to explore the underlying problem you’re facing (a large, slow server response), you’ll find other possibilities. You might implement infinite scrolling, refactor your database queries, cache search results, or even redesign your UX so users initially request more specific data. Forming a sense of the landscape will help you narrow in on an appropriate, effective solution rather than chasing a close enough one.
Beware of the XY problem — where, instead of asking for your actual problem, you ask about your best hypothesis, and get an answer to a whole other question. As you research, keep asking yourself: “Does this resource help me do X, the problem I just defined?” It might sound trite, but if the answer is anything like, “Well, it helps me do Z, which helps with Y, which is how I can do X,” you’ve probably gone too far.
Step 2: Be Selective About Resources
You’ll need different resources at different stages of the research process, so be cognizant of the type of resource you’re looking for. For example, if you’re struggling to understand the concept of hashing (a cryptography technique commonly used to obscure sensitive data), reading a tutorial on bcrypt (a popular hashing library) is probably not the best use of your time.As you search the internet, you’ll find roughly four types of resources:
- technical documentation (MDN, API documentation)
- tutorials (Medium, FreeCodeCamp, tool-specific)
- online discussions (Stack Overflow, Reddit, HackerNews)
- code samples from tutorials and forums
This may seem like a small change, but constantly evaluating if you’re looking at the right type of resource will force you to be more discerning, and will save you lots of time. It’s easy to get distracted reading a tutorial that sort of makes sense, but remember: your goal isn’t just to get the code working; it’s to write code you can understand and maintain.
Although the internet is full of knowledge, sometimes the most effective way to get an answer at work may be from your colleagues. Esther Leytush, a full-stack developer at Betterment, says her rule of thumb is to “google anything that I can frame as ‘How do I…’ and ask coworkers, technical leads, or managers when the question can only be framed as ‘Should we…?’ Your colleagues are the best resources on domain- and process-specific knowledge, and can often help you get unstuck. “If an obstacle that’s stopped your work for half an hour,” says Etsy’s O’Shea, “definitely take it to a colleague — maybe they’ll know the solution; maybe they’ll just commiserate.”
Step 3: Write the Code
As you narrow down your choices towards the solution you actually need, you can start looking for specific tutorials or documentation. Now, you can shift from trying to understand the landscape to finding and writing code that solves your problem.
At this stage, make sure you don’t copy over blocks of code without understanding every line. Many tutorials oversimplify the problem for the sake of brevity and clarity, but the sample code they use is often not suitable for production. Copying blocks of code will lead to technical issues when you can’t explain or maintain your work, and ethical issues around plagiarism and intellectual property. Moreover, by taking the time to rewrite and customize the solution now, you’ll find it easier to understand similar problems the next time.
Step 4: Careful research now = fewer roadblocks in the future
As with everything else in life, you’ll get better at research with practice. You’ll find it easier to reach the right resources using the right words, and the knowledge you gain from mindful research will illuminate areas of programming that used to seem daunting. “I’m more discerning about the solutions I find,” says O’Shea. “Instead of just copying and pasting someone’s hacky CSS, I’ll keep searching until I find the most idiomatic, performant, concise, or elegant way to accomplish what I want.”
So, the next time you run into a scary new problem, don’t immediately reach for Google. Define the problem, identify the resources you’ll need, stay mindful, and remember — this isn’t just how you solve the problem in front of you, it’s how you become a better developer.
Tags: bulletin, coding, mental health, mindfullness, research, software development
9 Comments
Doing research “Long Before” you start coding is not a good idea, sorry. You shouldn’t spend an entire week looking up things on the internet before you begin coding your project. You should figure out where to get started and then start right then.
Ultimately success as a coder depends on your willingness and ability to actually produce code effectively, research doesn’t grow that ability. Computer Science and software is one of the few fields where you can actually lack understanding of how things work and still use them effectively as long as you understand what they’re used for and why you’re specifically using it.
Knowing the implementation details may help you sometimes but it is exceedingly rare, the most important thing you can know about a software framework is how to use it and why you use it, knowing the inner workings is not important.
We don’t tell drivers they need to understand how there car works, they just need to know how to drive the car. The driver understands that it was engineered well and will do what it does well. The same is true for software frameworks. I know Django works and what it’s used for, I know when to use it, and so I can use to create full web applications no problem. I don’t know how any of Django is implemented beyond the API level, but that has never slowed me down in the slightest because the API level is all that concerns me. I didn’t research Django before starting using it, I just started and learned along the way because thats the only way to get any better at all at actually coding.
Couldn’t possibly disagree more.
Starting writing your code at hour #0 is the best way to accrue technical debt right from the outset.
You should be putting in *significant* research before you write a single line of code for your project.
Note that this does not include writing “test” or “experimental” code as part of your research, which is absolutely to be encouraged!
Kudos for teaching stackoverflow users to research more effectively. I think that quite a few users will benefit from these tips, and since giving such tips is off-topic on stackoverflow proper, I am very glad the blog has taken up the slack 🙂
That said, may I suggest a minor rewording? When you speak about “technical documentation”, might you actually mean “documentation from authoritative sources”? I mean, documentation being “technical” does not necessarily make it correct, but authoritative sources usually are.
I realize that official sources are not usually written in beginner-accessible language, but sometimes they are, and sometimes it is faster to painstakingly read one official source than to piece together an understanding from 10 incomplete and mutually contradicting blog posts written by random people 😉
PS: W3Schools is not an authoritative source, even though its name appears to imply this, and in my experience not quite up to date with current practices.
Short steps to take into consideration for everyday problems, in my opinion.
Don’t be affraid to ask, keep notes and focus.
I think most problems faced in the workplace are already solved in other projects and there’s not need to reinvent the wheel.
In case there’s a need to develop a new solution, these steps will guide to “I hope” (new)users to be more clear about its problems posted on the web.
When I was reading the beginning of the article, I was like arrarargahghrgharghargh no no no that is a terrible way to develop software what are you doing!?
Fortunately it then turned out that this is the whole point of the article, which is great. Nice work. 🙂
A few thoughts:
– Please don’t recommend w3schools. Yes, they’ve fixed a lot of big issues, but they’re still not that good and they still pay to win the search war rather than doing it with good content. MDN is more than adequate compared to W3Schools.
– Regarding your “four types of resources” bullet points, I see a couple issues:
1. Stack Overflow is not a discussion site like Reddit/Hacker News
2. Bullet point 4 seems to be nothing more than repeating bullet points 2 and 3.
In the years I’ve been doing this, the task of writing software has changed (duh.)
When I started, developers needed in-depth knowledge of their problem domain. If we used research to find good algorithms, they were usually described in academic papers. The occasional Byte article contained useful code, but typically had to be copied by hand.
Now, writing software requires encyclopedic knowledge. APIs are numerous and extensive. If just Mozilla’s Developer Network (MDN) were turned into a printed reference book, you’d need a pallet jack to move it. And, it would be obsolete by the time it was printed and bound.
Tens of thousands of easily downloadable libraries make our jobs easier. At the same time they increase the need for that same encyclopedic knowledge.
So we rely on our modern-day reference libraries. They really are cognitive prostheses, augmenting our intellect and memory. Unlike yesterday’s libraries, ours don’t feature helpful librarians who know where stuff is and how reliable it is. Stack Overflow and the other tech-social-media reference systems use voting to replace the librarians.
But none of it matters unless we actually read, evaluate, and understand the material we find.
Thanks for this awesome info
I learn a lots of things here. It is an amazing post , thanks for help me.