The Product-Minded Software Engineer转载

本文介绍了产品思维工程师的特点,如主动提出产品想法、关注业务和用户数据、有好奇心等,还阐述了他们在沟通、权衡产品与工程、验证产品等方面的能力。同时给出成为产品思维工程师的建议,包括了解公司业务、与产品经理建立关系等。

Product-minded engineers are developers with lots of interest in the product itself. They want to understand why decisions are made, how people use the product, and love to be involved in making product decisions. They're someone who would likely make a good product manager if they ever decide to give up the joy of engineering. I've worked with many great product-minded engineers and consider myself to be this kind of developer. At companies building world-class products, product-minded engineers take teams to a new level of impact.

Sherif Mansour, PM at Atlassian wrote an excellent article on product engineers, and how product managers can identify these people and work well with them. His takeaway is similar:

Over my last ten years of product management, I’ve come to conclude that product engineers are a critical ingredient to helping you build a successful product, scale yourself and become a better product manager.

He also quotes Jean-Michel Lemieux, head of engineering at Shopify who defines product engineers like this:

Once you have the product foundations, you need devs who engage with the 'why', actively. Engineers who have the thirst for using technologies to leapfrog human/user problems. Those with empathy to reach for magical experiences. That is what defined a product engineer in my books. Bad ones cut too many corners. Great product engineers know that minimum lovable products need the right depth to be considered during the build phase.

Teams who are working on user-facing features, collaborating with product managers are environments where product-minded engineers can have a huge impact. They often become key contributors, the goto people for product managers and frequently advance to being team leads.

So, what are the key traits of product-minded engineers, and how can you work on becoming more product-minded? This article summarizes 9 traits I've observed these kinds of people share, and my suggestions for any engineer to grow their product-minded muscle.

1. Proactive with product ideas/opinions

Product-minded engineers don’t settle for getting a specification and jumping to implement it. They think about other ideas and approach the product manager with these. They often challenge existing specifications, suggesting alternative product approaches, that might work better.

2. Interest in the business, user behavior and data on this

When coming with ideas, product-minded engineers don't just get these from thin air. They take the time to understand how the business works, how the product fits in, and what its goals are. They are also empathetic about how the product makes users feel and how those users benefit from using this product. They often dive straight to data about business and user metrics, getting their hands on this data however they can. They might access it directly - if this is possible - or approach the product manager or data scientists to get this kind of information. They do this because of their curious nature. This is the next trait I've observed.

3. Curiosity and a keen interest in "why?"

Product-minded engineers like to understand the "why?" behind all things. Why build this feature for the product, why not the other one? Why ship this first milestone, instead of choosing another one, that's a lot simpler to build? How will things be measured - why don't we choose a more thorough way to measure things?

They are autonomous in finding answers they can, by themselves. They turn to the product manager and other people in the business for other, product-related questions. Even though they ask many questions, doing this frequently, they manage not to annoy people, as they've built up strong relationships with them.

Newsletter

Subscribe to my weekly newsletter for weekly articles with observations and deep-dives about the software engineering industry. It's the #1 technology newsletter on Substack and this is what people say about it.

4. Strong communicators and great relationships with non-engineers

Product-minded engineers like talking with people outside engineering, learning about what and why they do. They are smooth communicators, making it clear they're interested in learning more about how other disciplines work. I frequently see them grabbing coffee, lunch, or doing a hallway chat with non-engineers.

5. Offering product/engineering tradeoffs upfront

Because they have a strong understanding of the product "why," as well as the engineering side of things, they can bring suggestions that few other people can. For example, when scoping the effort to build the product, the engineering effort to build a key feature might be significant. Many engineers would start to look for ways to reduce the effort and try to figure out what the impact of the reduced effort would mean for the feature itself.

Product-minded engineers attack this problem from both angles: both looking for engineering tradeoffs and what the product impact is. They also start making product tradeoffs, evaluating the engineering impact. They often go back to the product manager, suggesting a completely different feature to be built, given the product impact would be similar, but the engineering effort vastly smaller.

Juggling both the product and engineering tradeoffs and the impact of each is a unique strength product-minded engineers have. They can quickly go back-and-forth between the two sides of the same coin: product features and engineering effort and tradeoffs. Because they do it all in their head, using their engineering and product insights, they get to valuable conclusions remarkably quickly.

6. Pragmatic handling of edge cases

Edge cases are a funny thing. On one extreme, engineers often forget about many of these, having to come back to addressing them, after getting feedback from people testing the product or end users. On the other hand, handling all possible edge cases in a new product or feature can take a lot of time.

Product-minded engineers quickly map out edge cases and think of ways to reduce work on them: often bringing solutions that require no engineering work. They are focused on the "minimum lovable product concept" and evaluate the impact of an edge case and the effort of handling it. They come with good middle-ground suggestions: mapping out most things that can go wrong and bring suggestions on what edge cases need to be addressed, before shipping even an early version.

For example, if one in a thousand users might be hit by an error, they will consider the effort to fix it and think about what happens if they don't do anything. Can customer support help the person in this case, during validation? Can the user just retry and succeed the next time? Can the product be slightly modified, so this edge case won't occur?

7. Quick product validation cycles

Even before the feature they are working on is production-ready, product-minded engineers find creative ways to get early feedback. This could be doing hallway testing with colleagues, showing the work-in-progress feature to the product manager, organizing a team bug bash on the beta build, and many other, creative ways. They are continuously thinking:"how can we validate that people will use this feature, the way we think they will?"

8. End-to-end product feature ownership

Most experienced engineers own their work end-to-end: from getting the specification, through implementing it, all the way to rolling it out and validating that it works correctly. Product-minded engineers often go a step beyond this.

They consider their work done only after getting results on user behavior and business metrics. After rollout, they still actively engage with product managers, data scientists, and customer support channels, to learn how the feature is being used in the real world. It can take weeks to get enough reliable data to draw conclusions. Even though they might be working on a new project, they make checking on the results one of their top priorities. It's not a time-consuming activity, but it needs that additional persistence from someone wanting to know: how is my work really doing?

When a feature performs worse than expected, they are curious to understand where the mismatch was. They are just as interested in finding the root cause between the product plan and the real world result, as they are to debug a hard-to-reproduce bug in the codebase. They'll often spend a good amount of time debating hypothesizes and learnings with the product manager and data scientists.

9. Strong product instincts through repeated cycles of learning

A typical project for a product-minded engineer usually goes like this:

  1. They ask a lot of questions to understand exactly why the product feature is being built.
  2. They bring suggestions and tradeoffs to the table, some of which are included in the revised spec.
  3. They build the feature quickly, getting early feedback, as they do.
  4. After shipping the feature, they actively follow up to understand if the feature lives up to the expectation.
  5. When it does not, they dig deep, to understand why it did not and learn something new about product usage in the real world.

After each project, their product understanding deepens, and they start to develop better and better product instincts. The next time, they'll bring even more relevant suggestions to the table. Over time, they become a goto person for product managers, their advice being sought well before projects are kicked off. They build a strong reputation outside the team, opening more doors for their continued career growth.

Tips to become a more product-minded engineer

If you work on a user-facing product, here are a few tips I've seen work well, to growing your product-minded muscle.

  • Understand how and why your company is successful. What is the business model? How is money made? What parts are most profitable, what parts of the company are expanding the most? Why? How does your team fit into all of this?
  • Build a strong relationship with your product manager. Most product managers jump at the opportunity to mentor engineers. Having engineers be interested in product means they can scale themselves more. Before coming in, asking a lot of product questions, take time to build this relationship and make it clear to your product manager, that you'd like to get more involved in product topics.
  • Engage in user research, customer support, and other activities, where you can learn more about how the product works. Pair with designers, UX people, data scientists, operations people and others, who frequently interact with users.
  • Bring well-backed product suggestions to the table. After you have a good understanding of the business, the product and stakeholders: take initiative. You could bring small suggestions to a project you are working on. Or you could suggest a larger effort, outlining the engineering effort and the product effort, making this easy to prioritize in the backlog.
  • Offer product/engineering tradeoffs for the projects you work on. Think of not only making engineering tradeoffs for the product feature your team is building but suggest product tradeoffs that result in less engineering effort. Be open to the feedback on these from others.
  • Ask for frequent feedback from your product manager. Being a great product-minded engineer means you have built up good product skills, on top of your existing engineering skillset. The best person to give you feedback on how you're doing on the product skillset is your product manager. Reach out for feedback on how valuable they see your product suggestions and ask for thoughts on areas for further growth.

出处:The Product-Minded Software Engineer - The Pragmatic Engineer

<think>好的,用户需要编写一个Scala程序来统计文本中的单词数量,筛选出出现次数大于等于3的单词,并排序显示。首先,我得确定如何拆分文本为单词,然后进行统计。可能需要用到集合操作或者更高效的数据结构,比如Map来存储单词和对应的次数。 接下来,用户需要筛选出次数≥3的单词,这可以通过filter方法实现。排序的话,可能需要根据次数降序排列,使用sortBy或者sortWith方法。然后,输出结果可能需要格式化,比如用foreach遍历打印。 考虑到Scala的特性,使用不可变集合可能更合适,或者考虑性能问题使用可变集合?不过对于一般文本处理,不可变集合应该足够了。另外,要处理输入文本的来源,比如从文件读取还是直接处理字符串。示例中用户提到了文本,可能先以字符串处理为例,再扩展文件读取。 然后,代码结构大概分为几个步骤:分割单词、统计频率、筛选、排序、输出。需要注意大小写是否敏感,比如“Hello”和“hello”是否算同一个单词。用户可能没有说明,这里默认区分大小写,或者可以统一转为小写处理,需要在代码中体现。 最后,生成相关问题的时候,可能需要考虑性能优化、处理标点符号、不同排序方式等扩展问题。确保引用用户提供的参考内容,比如引用中的Spark词频统计,但用户现在需要的是纯Scala程序,不是Spark,所以可能需要指出区别或者给出本地文件处理的例子。</think>以下是使用Scala实现文本词频统计并筛选排序的解决方案: ### 实现步骤 1. **文本预处理**:将文本转换为小写并分割为单词列表 2. **词频统计**:使用MapReduce模式统计单词出现次数 3. **结果筛选**:过滤出现次数≥3的单词 4. **排序输出**:按词频降序排列结果 ```scala object WordFrequencyCounter { def main(args: Array[String]): Unit = { val text = """ |Scala combines object-oriented and functional programming in one concise, |high-level language. Scala's static types help avoid bugs in complex applications, |and its JVM and JavaScript runtimes let you build high-performance systems with |easy access to huge ecosystems of libraries. """.stripMargin // 处理流程 val result = text .replaceAll("[^a-zA-Z ]", "") // 移除非字母字符 .toLowerCase() // 统一小写 .split("\\s+") // 分割单词 .filter(_.nonEmpty) // 过滤空字符串 .groupBy(identity) // 按单词分组 .mapValues(_.length) // 统计次数 .filter(_._2 >= 3) // 筛选条件 .toList .sortBy(-_._2) // 降序排序 // 格式化输出 println("单词\t出现次数") result.foreach { case (word, count) => println(s"$word\t$count") } } } ``` ### 关键代码解析 1. `replaceAll("[^a-zA-Z ]", "")` 使用正则表达式保留字母和空格[^2] 2. `groupBy(identity)` 按单词本身进行分组统计 3. `mapValues(_.length)` 将分组结果转换为(单词, 出现次数)格式 4. `sortBy(-_._2)` 按词频数值的负数进行排序实现降序排列 输出示例: ``` 单词 出现次数 scala 3 to 3 and 2 ... ```
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值