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.

第1步：了解景观

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.

第2步：选择资源

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:

• 技术文档（MDN，API文档）
• 教程（Medium，FreeCodeCamp，特定于工具）
• 在线讨论（Stack Overflow，Reddit，HackerNews） < li>来自教程和论坛的代码示例
  

Start broadly — look for a Wikipedia article, MDN documentation, or W3Schools. When I was learning to research, I created a whole website, Hackterms, to crowdsource coding jargon that can sometimes be a stumbling block. Then, once you understand the concept at a high level, you can search for relevant blog posts, tutorials, and Stack Overflow responses to help you write code. If you browse message boards, don’t get caught up in the arguments about which tool is best until you understand what they actually do.

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.”

第3步：编写代码

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.

第4步：现在进行认真的研究=未来的障碍会更少

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