The Product-Minded Software Engineer - <AUTHOR> https://blog.pragmaticengineer.com/the-product-minded-engineer/ <comment><USER6> There is a con to being a product minded software engineer. When you are in organizations that do checkbox driven development (i.e. build features so it looks like your product has the widest feature set), it can be disheartening. You will ask why build this? and will get a believable answer. However, once it get's built you will notice that no one pays attention to the feature (no analytics, no reports, no iteration, etc.). At some point in the future, maybe a year or two down the line, you will notice a huge bug raised with the feature. Whoops for 20% of the users, it didn't work. You feel bad at first for your bug, but then realize, that no users even noticed the feature gone. Your suspicions that you were building something that didn't even matter are confirmed.

This has happened to me a lot. I was on a team that was on one of the "most important" projects to the company. We had the CTOs daily attention. You felt important and we had a large team who worked hard to ship it in one year. It was deemed a success by the CEO and myself and many of the team members got staffed on other teams (basically the next highest priority project for the company). Some other engineers got put on legacy duty for maintaining the project. After a year, I barely heard about the project (we had so many new projects) but we still maintained it and it was still on our website. 1.5 years later, I get a p2 bug that basically shows the whole product had stopped working for 3 months due to a front end bug. I got pulled to fix the bug and worked hard to find it and fix, but at the end I was demoralized because I realized my team had wasted a year on a feature no customer cared about enough to complain until 3 months after it stopped working.

Basically, it can be really demoralizing to be product minded engineer if your organization is not. This happened in an org that heavily talked the talk about product market fit and testing, but the truth was we were checkbox driven. We just wanted the widest feature set among competitors (even if they didn't always work).

<comment><USER7> > You feel bad at first for your bug, but then realize, that no users even > noticed the feature gone. Your suspicions that you were building something > that didn't even matter are confirmed.

Having been in a position where I was talking a lot to users, I can assure you that they _do_ notice. But they won't report it, just shrug and have a slightly decreasing opinion of your software.

<comment><USER8> Says a lot about software developers and IT in general doesn't it? That users would rather just work around the problem and continue doing their job than even bother telling us about it.

<comment><USER9> Well, it does says a lot about users too. The typical user would have a hard time describing a software problem beyond 'I don't know, it is just not working anymore'.

<comment><USER10> That is a terrible attitude IMHO - why should they have to have to learn how to talk to developers? Your cynicism towards "typical users" probably harms you and your career.

I find that the vast majority of _people_ are not stupid: they have learnt that trying to get things fixed is usually a waste of time. As a developer I truly understand this from when I've tried to get others to fix their software, and I am _very_ good at describing problems.

Regularly I am the one that created the software problem, and if I were a better developer I would have avoided making the problem in the first place (or had ways to detect it, or easy ways for my clients to tell me).

Edit: simplified.

<comment><USER9> > That is a terrible attitude IMHO - why should they have to have to learn how > to talk to developers? Your cynicism towards "typical users" probably harms > you and your career.

I think I'm sensing a bit of anger in your tone, looking how you move the subject on my person. Sorry if I offended you in any way, it was not my intention to offend anyone. Me and my career are ok so far, if that's of some relief to you.

We are surely not working in the same area then. Mine is as a vendor of enterprise stuff, for Big Corps. In my place, not relying in users' proactive and qualitative feedback is a pretty decent attitude in my eyes, it tends to deploying more reliable software, thus to invoices actually collected, which finally leads to having an actual paycheck.

</comment></comment></comment></comment></comment></comment><comment><USER11> I've met Gergely, the author, a couple of times a while back and he's a great guy and I think we work in a similar way. In the majority of my roles I was initially hired as an engineer but then moved to engineering management and the points highlighted in the article are very familiar.

I often found that features would be requested from product owners/business and developers would implement it no questions asked but at lunch time, developers would rant about the requested feature's value. When asked if it should be brought to the PO's attention, I often saw the attitude of it not being their problem, they're getting paid either way (whether that's a company culture issue, general developer apathy, or burnt by past experience of questioning management is a different question). I think product-engineers feel a bit more invested in the product and have the soft-skills to influence or provide feedback in a manner conducive to business listening.

In my teams, I try to foster this type of communication and I've noticed a lot more developers opening up and providing valuable product-orientated feedback which often has an upward positive spiral of them feeling more appreciated and speaking more. Naturally a lot of engineers still want to just code and go home but team culture can really highlight and encourage engineers who may not be confident to speak up initially.

Ironically, as someone with more engineering experience on paper, it's been tricky to find a job directly as any form of product or engineer manager, I always had to go in as an engineer then be promoted after a year or so which isn't always ideal (or referred via a friend). I feel Product and Technical skills are still often considered mutually exclusive a lot of the time but I think that's inertia from when technical skills were still considered a cost to the business.

<comment><USER12> Conversely, when such feedback and communication is overlooked or ignored, over and over, engineers often stop giving it even when they are interested.

POs in my recent experience could benefit from listening more to their developers, who often know the domain much better than they do. (Or perhaps the wrong people are becoming POs)

<comment><USER13> This, I've gotten pretty fed up with my current company because management just hands out work with no real explanation. Even more frustrating is that any significant technical design work is done in closed door meetings where the only people invited are development and product managers.

I've stopped giving feedback and I'm nearly at a point where I've stopped being interested. It frees up my mind and motivates me to work on my own projects on nights and weekends so I can actually have a say.

<comment><USER11> I've had this happen to me and seen it happen as a third party. It's a cultural issue and whilst I can see that difficult to change in large companies, startups with this mentality often demoralise developers quickly IME.

This is often how waterfall projects are/were run in large companies historically but now companies want agile everywhere but they don't implement the right processes to facilitate it. You end up with behind closed door decisions, promises made by PO that it will be done in the next sprint, and at no point has anyone with either the courage or technical know-how stepped in to point out that it's not feasible.

</comment></comment></comment></comment><comment><USER14> The spectrum of (product engineer) <\---> ($NEEDS_A_NAME) has been one I've encountered a lot and which I find is underappreciated in hiring and team- building.

The way I think about it is that you're giving weights to one of two different goals:

1\. Building the right thing

2\. Building the thing right

I've found that in early-stage work, you really really need to have engineers who are more interested in (1) than (2). I'd probably say a product engineer who's a good fit for early stage work probably has an 70%/30% mix of what motivates them between these two goals.

The strongest product engineers also have a keen sense of the power of MANUALLY handling some cases as a way to learn. At small scale, the cost of manually handling something can be way lower than building for that case. So another attribute I've seen is that strong product engineers are either okay with or even actively enjoy supporting users in those edge cases, talking with them as a way to learn.

I'd be curious to know how companies most effectively hire for and/or cultivate these kinds of behaviors in eng teams.

<comment><USER15> I'd say the word you're looking for is Software Crafts[man,woman] but I don't necessarily believe the two are exclusive, but rather horizontal and vertical axes.

There is a difference between someone actively making compromises between time to market and features, and someone who doesn't understand how to write software in a maintainable fashion but can get something quickly out to market. There are even people who are good at neither.

<comment><USER16> This is an understated point, there is a difference between intended technical debt and incompetence.

At a very micro level, yesterday I was looking at a simple JS object with 6 entries, and 3 different naming conventions. Doing even simple changes without code-completion in the code base is mentally taxing.

</comment></comment></comment><comment><USER17> This might sound like a rant, it probably is but I'm sick and tired of articles that create this perfect personna, meddle in theory but behave like they're sprouting truths. The ninja rockstar developer, the amazing product guy... I could write an article right now about any profession.

The reason you need the CPD (Coal/People/Dreaming) focused worker in your coal mine is bacause he will:

1\. Understand that coal is an important product.

He will give himself to this quest and personal mission to understand how people use coal and just how much society depends on it. This will push him to better himself in its exploitation.

2\. Be a dreamer.

Most people will just wave their hand and dismiss the possibility that coal extraction is a flatbed for innovation. Your coal focused worker will spend all his time thinking about new ways to work with coal. That will increase the creative output of the whole operation thus raising the bottom line.

3\. Be a people person.

Coal mines are dreary places that's why your 10x coal worker will have social skills. He'll need to keep the people around him entertained and challenged so that he may create friction value.

Anyway, turns out I can't write a proper article in one go but I will end this unsubstantiates comment by saying that most of these articles target the management type that makes ill informed decisions based on blog aricles, and the fact that this kind of feedback loop exists in the world infuriates me.

Later edit: just reread the article and got angry again. What's the value in this? Can we really throw such absolutes right now?

I'm sorry if the post author is somehow seeing this comment, it's not a bad post, it's a bad post type _in my opinion_ as it brings nothing new to the table.

Actually, it might make the reader feel like product developing is this weird arcane _science_ and that unless he has those attributes he's not this unicorn product engineer, when the reality is that _most_ product engineers can't become what is described in this article because the work they do is tied to reality, not to the rainbows and clouds world of our imaginations.

<comment><USER18> OP here. I've written this based on what qualities I've observed several of my engineering colleagues exhibit, who are pretty good at building products and working with PMs. And who consistently get stellar feedback from business stakeholders, certain teams going straight to them, to discuss new ideas.

I beg to differ the article is super generic, as it closes with very engineering specific recommendations to build a "product-muscle" for developer [1]. This is the kind of advice and coaching I give to devs around me who would like to make more product/business impact.

[1] [https://blog.pragmaticengineer.com/the-product-minded- engine...](https://blog.pragmaticengineer.com/the-product-minded- engineer/#tips-to-become-a-more-product-minded-engineer)

<comment><USER17> Of course I am not going to argue with the person behind the article as the simplest explanation is that I misread, misunderstood, misjudged etc.

However, I will ask you three questions to clarify this for me, of course optional:

1 - Do you think it's possible for one person to do half of the things you listed?

2 - Do you think it's possible for most product people to do most of the things you talk about outside of companies such as Microsoft, Uber and similar?

3 - Should the product minded engineer be interested in users or the stakeholders?

<comment><USER18> And I'm also not going to argue with people who have different experiences - <USER2> can speak for my own experience, and generalise it, finding others who might think similarly, which is what I've done here. This is to say YMMV. But to your questions.

1 - Doing half the things I listed. I hope this is not a loaded question, but I've seen people do all of them. It usually starts with people who are both good communicators, are curious about the "why" on things, being interested in how the business works. Then they bring product ideas. The nice you bring product ideas to the table, as an engineer, making pragmatic trade-offs is pretty straightforward (if we build a slightly modified feature, we can get the same business impact, but a lot less eng complexity). The rest is about looking out ways to get early feedback (prototyping, hallway testing etc) and challenging weird edge cases. The first few of these I'm seeing a lot around me.

2 - I don't fully get the question about product people. Also, I spent a good deal of my career working at Skype/Microsoft and Uber, so I don't think I can give a definite answer. If it helps, at Skyscanner, a smaller startup, I had even more product say as an engineer, than I did at Uber or Microsoft. I suspect everything I wrote assumes an environment where engineers are empowered and close to the product, and data about the product usage/revenue generated.

3 - I'd say have a lot of curiosity on how the product works and how users use it, and generate value for the company. Then you need good communication skills to build trust with the product stakeholders - to understand more about the business, how they think, and to be able to showcase your ideas, prototypes and accommodate feedback for them.

<comment><USER17> I did a little read through again and noted down my thoughts.

This is mostly in relation to my view that a single person ... would have trouble, with filling all these roles within the 8 hours given per day and under the assumption that he actually understands them all and is not just winging it.

And I do get

Sorry for the sarcasm in the writing, it's who I am and yes I do feel bad sometimes.

—

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

Do you do this for every backlog item? I have assumptions about all tasks I receive and sometimes believe them to be less than ideally researched. Do I challenge all the time? I feel like that would land me in a bad place with multiple people over time.

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

This is just a part of the paragraph, there are more ideas about user preferences and data analytics. Business is constantly changing, the product should ideally pivot based on user needs, goals change at least ocasionally.

In order to keep this loop going I personally feel like I either have to half ass it and pretend like I understand so we can get the release ready by the deadline or actually do this properly and that feels for me like a full time job rather than a bullet point to do on the side as an engineer.

Sure, I can say I look at analytics and talk to users, set up blind interviews and calls all the while following the business moves but _in my case_ I would most likely be an impostor unless this would be a pretty large part of my work.

> Curiosity and a keen interest in "why?"

Just pasting headline from now on as there is a lot of text.

This paragraph encompases the job title of business analyst, project manager and business intelligence.

Let's just assume I do have time in my workday for developer, business analyst, project manager, business intelligence and business strategy.

So all the points up until now, I can do cause I am amazing. And not just half ass them but fully get the 'why' and understand them all.

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

I know I said I'll paste the title but this one flows nicely. Also, I am obviously a bad communicator but an amazing marketing and sales guy cause I spend the time talking to them about what they do all the time. But this is just fun chat, understanding new domains of expertise, I can squeeze them in my daily 8 hours.

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

Architect, strategy, consultant. EZPZ I am 10x. But it's doable, probably becomes annoying after awhile but with the time I spent analyzing all my product users and doing reports on them I probably come up with better ideas than my colleagues who work full time on this.

> Because they do it all in their head, using their engineering and product > insights, they get to valuable conclusions remarkably quickly.

Oh, I thought this was based on user data, nvm I just do it in my head. I don't need no data, I read it once and now my trimatrix quantum brain will just curve fit for the optimal solution. I think my colleagues love me for my mental abilities.

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

I love how my whole team always has time for my ad-hoc bug bashings. I thought I was the only one with the time needed to handle ~ 10 roles to perfection.

> They are continuously thinking:"how can we validate that people will use > this feature, the way we think they will?"

A little bit of psychology right here, nothing much, will fit right in my schedule, I'm only around 50% filled.

> 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?

Oh, just some weeks of daily context switches to check on my baby. No boss, I'm also working on the other tasks for which I needed to do all roles, but I also log and audit the feature. Don't worry, it's not a time consuming activity, I just need to:

> spend a good amount of time debating hypothesizes and learnings with the > product manager and data scientists.

It's ok, I just need to brush up on my data science. 51% filled.

Alright. What next, I still have 49% of my daily 8 hours. Oh I know, I'm going C-Level!

> 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?

I don't need no CEO, CFO, CIO and / or ang form of c-level. I got this guys.

There's something missing though, my 8 hours are filled with so many roles and I am still bored. I know!

> Pair with designers, UX people, data scientists, operations people and > others, who frequently interact with users.

Can't wait to brush up on my design and UX, luckily I already know Data Science and Operations from my other roles. I'm sure I won't bother the UX all that much, he probably doesn't do a lot of stuff anyway cause he's not a product engineer.

—

Anyway, I feel real bad for having you on the end of my stick for what is really not a bad article. Just caught me frustrated with some aspects of it and saturated. I think your insights are valuable, a good guide, but maybe a bit too demanding of the role you are tryint to define.

So again, I am sorry, I know it's not the easiest thing to get out there and be exposed to unfounded criticism but these were my 2c.

Best of luck!

<comment><USER19> There are several points here where you assume that as an engineer, you need to learn to do another job entirely, here:

>This paragraph encompases the job title of business analyst, project manager and business intelligence.

>Let's just assume I do have time in my workday for developer, business analyst, project manager, business intelligence and business strategy.

Here:

>Architect, strategy, consultant. EZPZ I am 10x.

Here:

>I thought I was the only one with the time needed to handle ~ 10 roles to perfection.

Here:

> It's ok, I just need to brush up on my data science. 51% filled.

Here:

>I don't need no CEO, CFO, CIO and / or ang form of c-level. I got this guys.

>There's something missing though, my 8 hours are filled with so many roles and I am still bored. I know!

And here:

>Can't wait to brush up on my design and UX, luckily I already know Data Science and Operations from my other roles.

But I think the point you're missing is that you don't need to do all those jobs fulltime, you just need to have a baseline level of understanding of the underlying principles and needs of those roles. Which isn't that crazy - <USER3> "product manager"/"product owner" roles are a smorgasbord of skills and responsibilities, and most people who fill those roles aren't experts in every single skill and responsibility, just like every engineer isn't an expert in both kernel code and frontend frameworks.

The way I see it, the "product engineer" is between a product manager and a full stack engineer - someone with a certain level of understanding of different parts of the code, and different parts of the business, but not an expert at any. A generalist whose generalist skills go beyond just the engineering domain, but that doesn't mean they're specialized in all of those skills.

Is it easy to acquire all of those skills, even to the generalist level needed to be useful even though you're not an expert? No, of course not. But you also don't have to do it all at once. Doing any of the items on this list can add value, and once you get used to doing it, it's part of your daily routine. Then you pick up something else. It adds up over time.

<comment><USER17> I understand you need to be a bit of everything.

When we talk on HN about managers that have technical competencies and try to get into the development process we bash them for thinking they understand, but we sometimes argue that we need to understand and do all roles and it works...

I could make any list of desirable characterisics and it would make those that follow it better professionals. Does the list of OP not match any other job than product engineer? Would a tester not be a better employee with the same understanding, or an HR person?

<comment><USER19> >When we talk on HN about managers that have technical competencies and try to get into the development process we bash them for thinking they understand, but we sometimes argue that we need to understand and do all roles and it works...

I can't speak for every conversation on HN, but personally, I have no problem with technical managers that know what they're talking about, as opposed to non-technical managers that attempt to make technical decisions. If someone is trying to be a 'product engineer' but doesn't have the first idea what they're doing about anything beyond software development, I agree that would be counterproductive.

>I could make any list of desirable characterisics and it would make those that follow it better professionals. Does the list of OP not match any other job than product engineer? Would a tester not be a better employee with the same understanding, or an HR person?

Well, it matches the job of... product. Which hasn't always been a separate job from software development, and in some companies it still isn't.

I think there's a distinction to be drawn here, though. An HR person certainly might benefit from insights into the company's business, talking to customers, etc., and it very well could make them more effective at their job. But for the person building the product, it's more relevant to what they're doing every day, since it directly determines both the input and output of their work. I suspect sales has a similar dynamic - understanding the customers and the product is going to highly relevant. A software engineer who just completes tickets and focuses only on purely technical problems might be effective, just as a salesperson who thinks that selling cars, selling software, and selling biscuits are all the same process might be effective, based purely on talent in the relevant skills (strong technical skills for the dev, strong interpersonal skills for the salesperson), but I'd expect the same person to be much more effective if they added some of these product skills, where the force multiplier isn't quite there for HR or Accounting.

Of course, not every skill is going to be helpful for every role. As a software engineer, interpersonal skills are likely to be very useful, but learning to close a sale probably isn't going to have much benefit. The point of the article is that the author finds that software engineers who have these product skills are much more effective at making good software than software engineers who don't.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> As a PM I would agree that some of these traits are really able to increase team effectiveness. For example, just in a recent project, we saved weeks of work after asking the developer to be more upfront about tradeoffs.

However a big, big caveat on #1 "proactive with ideas/opinions" and #3 "curiosity and keen interest in 'why'". These are also traits of a different kind of engineer — the opinionated one _with poor product insights_ and who _isn 't interested in feedback_ and constantly derails the team by sharing their thoughts on what we should and shouldn't do.

Of course I prefer working with an engineer with product opinions and who asks why than one who doesn't, but if you're an engineer who's looking at this article and thinking "oh, this says I should start blurting my opinions out about the product more often and asking people why they are doing things the way they are", well that doesn't work well. To be really efficient I think you need to look at it more as "I should share and be curious about whether my insights on product and strategy are valuable to the team", then listen to the feedback about it.

<comment><USER21> As a product manager you should not be asking anyone to build you anything without properly explaining the why. It starts with the why, and a good engineering team will offer how+when. If you get overly involved in the how you'll end up with ignoring that insight and the responsability that comes with it.

Being on both the side of product and engineering, more often than not it's a lack of collaboration and trust between the two that leads to poor products and frustrated engineers. Your last paragraph hints at this.

 _Poor product insights_ \- some of the most competitive features I've seen make it into a product found themselves there because an engineer decided to build it to fix a pain point of their own (often after having that feature request ignored by product owner)

Humor your engineers and give them creative ownership over a feature (from suggestion to implementation)- you'll be surprised how effortlessly it comes out.

"I should share and be curious about whether my insights on product and strategy are valuable to the team"

Good advice for everyone in the team, wish it was followed unilaterally.

<comment><USER20> > "I should share and be curious about whether my insights on product and > strategy are valuable to the team"

> Good advice for everyone in the team, wish it was followed unilaterally.

Indeed, and this is how I approach my responsibilities as well. I grew myself in service of the team rather than telling people what to do / not to do.

> Humor your engineers and give them creative ownership over a feature (from > suggestion to implementation)- you'll be surprised how effortlessly it comes > out.

From firsthand experience, it works well sometimes, and when it works it's really magical. But it unfortunately doesn't work every time, because some folks really just want to be told what to code (don't want to engage), and other folks want to engage but don't have the skills (creativity, awareness of the pros and cons of various relevant UX patterns, user testing, etc). I give as much creative ownership as possible and really wish it could delegate it entirely though (does make my job easier).

</comment></comment></comment><comment><USER22> > They're someone who would likely make a good product manager if they ever > decide to give up the joy of engineering.

Read: If they ever decided to stop working and start siphoning funds to start their own company.

When companies are small the engineering managers are the product managers and the product is good. When a company reaches the point of over-reaching they divide their concerns and hire managers who don't know how to build the product and are paid to act like they are doing so while whipping engineers who have no interest in the product. Big companies that make good products do so by provisioning small teams with personnel who are essential to their collective goal. They mimic the small company.

<comment><USER23> Accurate

</comment></comment><comment><USER24> I am a "product minded" developer and feel absolutely murdered after a couple years at a large European tech co. The product, and teams, and goals, and people, and managers and everything at all keeps changing over and over and I never really see my efforts amounting to much. New people assigned to projects come with their own agendas and all that you worked for is now forgotten. The relationships you built don't matter anymore.

At this point I think life would have been a lot easier if I did _not_ care about product - and now I realize many have figured this out sooner than I.

<comment><USER25> I am sorry to play the devil's advocate but aren't you one of those with their own agenda's too? It's just matter of perspective how to judge yourself vs others, and putting yourself into the `good guys` camp seems biased to me.

<comment><USER24> A few examples: top-rank dev preserving power by slowing down growth for everyone, designer pairing with executive to sidestep decision-making - <USER4> destroy previous work by the team in the process, new people looking solely for promotions, new managers caring more about looking good than helping the product stay on track (i.e. replacing a very well-planned roadmap with vanity or metrics-hacking features). Most of these result in developers now working on things that have no real impact or don't make sense for the product, and it hurts.

You might be right, and it's not fair of me to expect everyone to have the same driving goals, but I simply miss the ability to focus on building something good (for customers and the business) and everyone being in tune, instead of catering to an endless stream of personal needs. Worse, in order to "perform well" it forces you to prioritize saving face and pleasing people over actual product/design/engineering, since half of your peers don't care, or will be gone by next cycle.

</comment></comment></comment><comment><USER26> I love product engineering. It's generalist++, and what I believe _most_ software projects need. However it is seen as a forbidden art in many workplaces with strongly-defined structure.

I thought working at a tech "startup" was a perfect place for a "product engineer". Trouble was, this startup was born out of a big ol' corporate. Despite the mantra "we are a startup and have cast away the shackles of our corporate mothership", acting as a "product engineer" was firmly rejected due to the company's corporate roots. I'll never forget the conversation with my (corporate-sourced) boss: "thinking about those kind of things is the job of a product owner - maybe you should consider switching roles". My heart sank. I didn't care about my job title.

So it turned out that I was treading on corporate-rooted toes by encroaching on other people's areas. We weren't all tending to the same garden - <USER5> had carved out their sections. It was how they added value and they weren't prepared for someone else getting involved in their areas. It sucked. And it's all too common, especially as organisations grow. Since then, I've made the way teams work a bit of a special interest of mine.

Culture, or the way things are done, is the primary factor that leads to declining performance of teams over time.

I'm also on the lookout for high quality jobs where I can stretch my legs. I'm a fullstack dev who gets involved in _everything_. I'll lead your team whilst you're not watching. I'm often hired to do stuff for which I have no experience. Do get in touch if you need someone like me.

<comment><USER27> I'm like you (and also looking for a job) and I think companies are scared to hire someone that can do everyones work better. But as its very tempting to dip into evey jar I appreciate that the others are there so that I can concentrate on what Im most productive at.

</comment></comment><comment><USER28> I hope this article raises visibility of this mindset in engineering management. I've always found product management very appreciative of the product-minded engineer, but engineering management to be apathetic at best. Engineering management is responsible for the engineer's career, so their ability to make the politics work out is critical. For example, minimum viable needs to be viable, which costs more than the minimum that engineering was incented to deliver.

<comment><USER29> Agreed. Most organizations I've been involved in will reward engineers for creating 20k lines of code that don't solve a relevant problem over the Product Engineer who creates 5k lines that solves valuable problems. The Product Engineer Genba'd out of the building to see what was needed and created the right thing, but since engineering management is often myopically focused on metrics disconnected from value the Product Engineer is significantly undervalued.

Combining ability with domain knowledge is extremely valuable, and a significant portion of domain knowledge is gained by stepping away from the keyboard.

Lean borrows the Japanese word Genba to describe this, which means 'actual place' or 'scene of the crime' and this Product Minded Engineer is somebody who is willing to Genba!

<comment><USER30> Why did they have to use 現場?

Wouldn't "in the field" suffice as a term here?

[https://www.dictionary.com/e/slang/in-the- field/](https://www.dictionary.com/e/slang/in-the-field/)

<comment><USER29> From my understanding lean came out of Japan, so some language seeped in.

I like to use it because sadly in-the-field has negative connations to a lot of software engineers from being deployed on site via white hot angry customer escalation.

Tldr; Genba's got no ptsd!

</comment></comment></comment></comment><comment><USER31> Product Manager here with computer science background. In my 10+ yrs as PM I have encountered engineers that I broadly classify in 3 buckets.

A) Product/business concerned eng as described in the article

B)"Know it all" product defensive eng

C) Pure technical focused eng

Working with #A is a great experience where not only do you move the product forward but learn a ton yourself.

Working with #C is great especially for products that are driven by well defined roadmap.

Working with #B is pure hell that I don't wish even on people I hate.

<comment><USER32> > B)"Know it all" product defensive eng

This is why I say often the best trait of a developer is humility. If you cant handle someone telling you where you are wrong you are slowing everyone else down with your dumb ego. Software bugs happen. To. Every. Single. Developer.

<comment><USER29> Amen, we're human developers, not compilers. A long time ago a colleague was reviewing some code I wrote and he noticed I was uncomfortable with all the stuff he was finding and he said "listen, we all miss stuff"

He's still right all these years of experience later.

<comment><USER32> Yeah, I used to have this problem myself, and now if I ever do the whole egotistical thing it's between friends joking around, or against someone on a forum whose being egotistical and I usually add references against their programming urban legend logic. I think some of us enjoy programming so much and it's like such a magical thing finding one thing you enjoy and are capable of doing that you forget you're _always_ going to learn something new. I meet great programmers who have no idea about front-end web dev or even the opposite, amazing front-end developers who have no idea about back-end, and nowadays mobile that dont touch either! Then there's other niches altogether that dont care about any of the aforementioned disciplines / branches of programming (heck, systems engineering and such).

</comment></comment></comment></comment><comment><USER33> I have found that, very roughly, some engineers are driven mostly by solving technical challenges and some are driven by building product ("product engineers"). Neither is superior or more capable. Different teams need different types.

Ask yourself what work you've done you're most proud of and why, and you can know your rough archetype. Then find a place where you will be rewarded for that type of work.

</comment><comment><USER34> To me "Product-minded" engineers defined here are mostly engineers who has the willingness to go "above and beyond".

Some may have this willingness because of their intrinsic nature. Some may have had this willingness but it slowly eroded because of many external factors (i.e. not getting recognized or compensated for their "above and beyond" work). Some simply have other priorities in their life (which I understand 100%, I suspect I'll be in the same boat if I had kids).

I've always seen myself as a "product-minded engineer". However, recently I'm struggling with keeping that mindset. Part of it is because of external factors and part of it is because I've also started to prioritize my personal life more. I do recognize that this is not black and white but rather a spectrum but it is so much harder to be fully engaged to a product when you are not giving it your 110%. :P

That being said I also believe it's also up to the company to foster and reward this kind of engineers, instead of just asking engineers to be a "product engineers"

<comment><USER17> I relate to your point of view and vented my frustration at the article.

You mention companies fostering and rewarding and I wholeheartedly agree. But not just engineers, _anything_ that creates value for the customer.

I believe that the best products have the whole mission aligned and going to the process of analyzing, testing, implementing, monitoring... then you don't need superstars, you just need good people with a clear positioning and direction. I think it's a simpler recipe than fishing for diamonds.

Getting an 'awesome product guy' cause you read it in a post is not going to create a magical unicorn that you can ride to VC-Land.

You need a clear positioning of your company towards the product and the users and then you don't need John Carmack, Steve Jobs and Carnegie in your tram to launch your new CRM, you just need to listen to your users and perhaps disregard a lot of blog posts along the way.

</comment></comment><comment><USER35> The ghostwriter software engineer: Do all the thinking, planning and work, receive no credit for it.

<comment><USER36> indeed... that is what majority of good software engineers are. they have spent their lives sticking to computers and therefore are not good at schmoozing people... hence they are often not credited at all.

</comment></comment><comment><USER37> I hate this line of thinking. If you're the kind of boss that makes your devs jump through hoops before you're willing to empower them on product-level decisions, your devs hates you and your product is suffering from your micromanagement.

Empower your devs right from the start and stop pretending that you know better than the devs who live and breathe the product every day.

</comment><comment><USER38> > "minimum lovable product"

I love that quote, and idea. Going to use it moving forward.

</comment><comment><USER39> One question I have when I see articles like this is: what are the _downsides_ of this sort of person on a team? What kind of projects should they _not_ be involved in? When are they the wrong person for the situation?

<comment><USER40> They will probably not be an extremely deep expert into specific technologies, and they will burn out on doing work that does not involve improving the product for actual users.

They want to deliver a feature, and sure they want to make sure it's being used well, but they won't want to stick around to endlessly tweak it.

<comment><USER41> I don't necessarily agree. Being a responsible product person both means tweaking good features, sunsetting bad features and introducing new ones.

</comment></comment></comment><comment><USER42> >minimum lovable product

If I ever hear anyone say that in real life, I will die on the spot.

<comment><USER43> That was pure cringe.

</comment></comment><comment><USER44> This advice might work at Uber or as a consultant but for FTEs it sounds like a great way to get fired. I consider myself a product-minded software engineer, but trying to be this person has been a sisyphean task pretty much anywhere I've worked. In fact I have come to view that impulse to challenge assumptions, to strive to do work I'm proud of, as an example of my naïveté as a junior developer. Executives are not too interested in quality software; they are interested in shipping whatever is in their head, whether it's good for customers or not. In startups they are interested in shipping literally anything at all to meet insane growth targets so they don't lose funding or get replaced by the board. IME the only time interest in the product actually helps engineers is during the initial interview where you need to demonstrate your interest in the company's mission. The reality is that despite how brainy the job happens to be, employers do not pay developers to think; they pay us to do the geek stuff they don't understand. They view us, if you will, as pure functions that take a set of orders as input and produce a functioning app as output—no side effects please. This is why we're going to be replaced by AI as soon as it's good enough, and are currently being replaced by no-code products: we are already robots to management.

</comment><comment><USER45> Anyone having or willing to practice all of that should probably just create his own product... Or at the very least should be paid quite a bit more than the managers. Sure, I think that about engineers in general, but even more in this case.

> minimum lovable product

Wow, had never seen that one. I feel like we have reached peak "elevator pitch" speak.

</comment><comment><USER46> I've been calling myself a Product-focused Engineer the past couple years and found it has been an effective way to express what kind of position I'm looking for and skills I bring to the table when job searching. Glad to see this topic proliferating more.

</comment><comment><USER41> I was soul searching for a while after reading the article and the comments. It is not easy to become a person (engineer or not) whose product ideas others trust in e.g. a single product company. It is doable though as I know one guy who is described in the article from work.

How I can become one of those guys? That is a relevant question to ask if you want to change. I think what the article misses as a good advice: have great engineering skills and then you will have time to learn other things. But first be really good in tech, that is your foundation. That's why you will be a product engineer, not a product person.

<comment><USER47> Depends, I reckon most of the audience here has the opposite problem, i.e. great engineering skills, but bad feature prioritisation skills—which can be attributed to relatively poor people skills.

</comment></comment><comment><USER48> It's called requirements analysis. I think it's primarily a social/political challenge because it means asserting yourself in areas where business people presume to be expert or may have been (often wrongly) given direct authority. A big reason some people are more assertive about fixing requirements is that they may have more social/political standing/skills than others. Often it's not because they are the only ones who know better.

</comment><comment><USER49> This article gave me chills of full product manager stack developer: a guy who will be involved in all things to the point he makes it all.

<comment><USER30> Indeed.

I'm not close to product development anymore in my dayjob but when I was I used to be very product focused, often even more so than the product managers I've worked with.

There often was no spec, no clear vision, and definitely a lack of understanding of the product details. So, when you are an engineer who cares about the product/company what do you do? You fill in the blanks, you do the scoping, you do the project management, you write the documents to explain everything to other teams. And of course during that time you engage with the product manager to get signoff.

In the end though you are doing a lot more in total and a lot more work the product manager should have been doing. And it's not easy because you come to other teams/stakeholder from a position of less influence than a product manager. In the end it's still the product manager who reaps a lot of the reward and ownership for the product.

The benefits of the product focused engineer for product managers and the company are obvious but what are the benefits for the engineers? Do they get more compensation? The article mentions they get to become team leads eventually, but it's not a given that product focused engineers want that.

</comment></comment><comment><USER50> I have been working in a company that even developers didn't want to use the product they built. They couldn't reach the "real" product owner and express their views, or there were too many product owners, especially in enterprises. All-hands meeting helped a little but it became politics when this came to public.

</comment><comment><USER51> At Google this is called UX Engineering. An experienced focused engineer that works with UX Design to build prototypes of future features, products and systems. I currently am working on multiple products that only exist because I straddle UX, Engineering and Product.

<comment><USER52> you are right. The goal of the research phase of the ux design process is to understand the users' goals, needs, values, knowledge and mental models. The design phase is aimed at identifying solutions that are able to satisfy those goals and needs (better than the competitors) and, at the same time, the goals of the stakeholders.

The "Product-Minded Software Engineer" is someone who has the opportunity to be informed by the analysis of the user research data, and offers his or her technical support to translate ideas and design in a working product or service.

</comment></comment><comment><USER53> Are there roles that target product developers ? What would that be called when searching? Product engineer, project dev etc ? Would the interview be different?

</comment><comment><USER54> One great addition to this article would be to propose some pragmatic examples and explain ways where people with different engineering philosophies would approach each example.

This can be a risky thing to do because readers in their heads, and people in the comments section "out loud", may end up debating the minutiae of the specific example instead of the broader philosophy.

But it's also very pragmatic, which is, like, the point, right.

Give us some worked examples of times where the product-minded engineering approach becomes relevant and we'll be readers who are more likely to understand your vision.

Let me pick a few examples, I'm not sure all are good/bad, but they're all cases where different kinds of engineers might do different things:

(1) We're building a web store. Do we insta-fail all orders that fail a fraud check, or do we let them go through but cancel within 24 hr (before fulfillment) if they haven't been manually reviewed, or what? If the fraud vendor has an outage what do we do with orders we get during the outage?

(2) We're building a feature which mirrors something provided by a direct competitor and should really exist. The UI the PM has specified is ugly and he knows it and I know it but we have no design resources committed to the project and timelines are pretty tight. Should I just build what he specced and move on, or what? Is it my job to make sure the business has accepted the limitations of this UI?

(3) I was glancing at a pull request that shipped last week and I found a bug in our product which could expose user data to third parties. It's not my code (I used to own this product area on a former team two years ago) and I have other sprint work to ship. Also it's pretty obscure so I doubt anyone is using it, but what should I do with this knowledge?

(4) I'm building an internal tool that is supposed to speed up development work. We wrote a spec for the tool based on what the hard parts of the process feel like to us, so, great, right? We're just gonna announce it? Does this feel a little hollow, should we maybe have interviewed some of our peers or colleagues first, or measured their work, to make sure we're building what they need? How do we even do that and how much time should we spend getting good at that before we go full steam ahead on the tooling?

(5) A friend showed me a pretty bad bug in our product where sometimes we show a blank screen instead of the data you requested. I checked and it turns out no one is measuring how often that bug happens to anyone, the product is kind of messy in terms of how we gather customer feedback, and it's not on anyone's roadmap to fix. Should I do something about that? What?

Just some thoughts.

</comment><comment><USER55> Product minded engineers with strong UX/design talent. How common or rare are they?

</comment><comment><USER56> > Build a strong relationship with your product manager.

this x1000

</comment><comment><USER57> oh hey look, the new buzzword. We're no longer paying out the nose of the 10x programmer. oh no no no no, we're now paying out the nose for the product minded programmer.

</comment><comment><USER58> In my opinion this kind of engineer sounds great on paper.

I personally much prefer working with people who put data before their ego and work towards the goals of the team and the business - and challenge only when there are reasons to do so -and avoid debates and the illusion of knowing what's best for the user in every situation.</comment>


Network.framework: A modern alternative to sockets - <AUTHOR> https://developer.apple.com/videos/play/wwdc2018/715/ <comment><USER3> I think quite a few of the hyperbolic comments here haven't seen any of this video and are just reacting to the title.

From what I can gather from watching this so far is, it just sounds like a layer you can optionally choose to use on-top of sockets that manages things like: TLS, multiple networks (4G/3G/Wi-Fi), DNS resolving, proxies, etc for you so you don't need to write it all yourself from scratch every time.

Maybe I'm wrong about that, or maybe none of this is actually as hard as it sounds in practice. But this seems like it might be atleast some what useful.

<comment><USER4> > I think quite a few of the hyperbolic comments

That's what you get from things like deprecating OpenGL and replacing it with a non-multiplatform alternative: bad reputation. They should ask Microsoft if it's easy to get rid of if once you have it.

<comment><USER5> I'm not a graphics programmer, but everything I've read about OpenGL tells me moving to Metal isn't some embrace/extend maneuver but more likely due to the fact OpenGL is steaming ancient garbage. Kind of like the types who once complained that MacOS wasn't built on X Window (chortle)

BSD sockets isn't a bastion of extensible interface design, it basically amounts to one giant ioctl() in every operating system. Darwin has weird escape hatches built into it (AF_SYSTEM) much like Linux netlink, and protocol parameter documentation is strewn across 5+ man pages each documenting a different set of magic value combinations for non-portably controlling some part of the stack. TCP_USER_TIMEOUT? That's one of many, many Linux socket options, but it's part of our precious so-portable socket interface we must maintain forever!

OS X chooses to bury its system call interface too, it's always been considered a private detail of the C library. I see no reason why socket() and friends couldn't similarly be forgotten. If some clean 21st century redesign of an ancient API has knock-on effects for the structure of code in open source projects across the ecosystem, that's probably a good thing in the long run. Progress never happens by hugging the past, especially when that past is ugly and filled with horrors

Try not to look at this as "hey, MacOS is breaking precious UNIX", but more as "hey look, why can't Bonjour+multipath TCP be a one liner on Linux too?"

<comment><USER6> OpenGL is certainly old and warty but it is nothing like X11.

I think people would be ok with Apple dropping OpenGL if they supported Vulkan, but their motivation and desire to lock people into Apple-only APIs is so obvious and transparent... Why would you support it?

At least Microsoft works with third parties and acknowledges the existence of some standards. Apple are always like "Here is the Apple way. I mean, the way. Because there is only Apple. Apple is the whole world and nothing else exists."

<comment><USER7> Which makes sense from a business point of view. Obviously that doesn't always align with a hacker mindset but there is a reason Apple is worth almost a trillion dollars.

<comment><USER8> Exactly, Apple has 1B devices that can run Metal on their GPUs, why shouldn't they write their own library?

</comment></comment></comment></comment></comment></comment><comment><USER9> Am I the only one whose first reaction to this is "Oh, great, yet another manner in which my next application won't be cross-platform?"

My second reaction being: "Oh, well, I'll just make it a web app instead of a native app."

 __edit __Rephrased the last sentence.

<comment><AUTHOR> Not everyone cares about cross-platform, some developers rather specialize in a given platform.

You can keep using sockets if that is your thing.

<comment><USER9> > Not everyone cares about cross-platform, some developers rather specialize > in a given platform.

True.

> You can keep using sockets if that is your thing.

For the moment, yes. However, as you know, earlier this week, Apple has officially deprecated OpenGL and OpenCL, a few years after introducing a competing (and admittedly suprerior) API. It is my understanding that Apple has not attempted to get this replacement API standardized, nor to offer it on any other platform. While it's hard to deduce from such a small sample, this precedent does suggest that the days of sockets are numbered.

This would make the life of some of my colleagues quite more complicated, and it would, in time, simply get rid of the macOS version of a number of existing cross-platform applications whose authors have neither the time nor the energy to rewrite the network layer.

<comment><AUTHOR> Every effort to get rid of plain unsafe C APIs is a plus on my book.

Apple has enough business with developers that care about macOS experience, not plain ports from other platforms.

When I buy a computer with a specific OS, I want the experience provided by the OS APIs.

<comment><USER9> I understand your point. I also dislike a lot these plain unsafe C APIs.

However, I am a developer. When I write an application, I only have so much time to spend on ports. Anything that requires me to have different designs for different platforms is bad for me. So, in the ideal case, we'll end up with a few high-level cross-platform abstractions (which may actually share Network.framework's API, for all I know) on top of networking, and everybody will remain happy. In the worst case, we'll end up with bits of duct tape, or simply with fewer macOS apps.

Also, even as a macOS user, most of the applications I use daily are cross- platform: Firefox, Thunderbird, VSCode, my various compilers & interpreters & debuggers, VLC, Gitter, Open Office, Terminal, games, etc. In fact, looking at my recent applications, the only single-platform applications I seem to be using are Keychain, SimpleComic, Instruments (the only one in the list to particularly integrate with the OS), Notes, Calendar. I sometimes use Pages and Keynote, both of which have nice UX, but the niceties don't strike me as particularly OS-integrated.

As I mentioned above, everything that makes it harder for developers to add macOS to their list of targets encourages them to not port their app to my current OS of choice. I'm thinking of, well, many in the list above, including games.

This is, I imagine, part of the reason why so many developers left single- platform development for web development. At least, that's my reaction.

<comment><USER10> > This is, I imagine, part of the reason why so many developers left single- > platform development for web development. At least, that's my reaction.

Spot on. You even gave an example of this: VSCode. If Microsoft is doing it, you can bet loads of other people are.

</comment></comment></comment></comment></comment></comment><comment><USER11> This thread confuses and saddens me. What is with the absolutist compulsion that every API and framework has to be cross-platform? Cross-platform APIs and frameworks must, by necessity, paper over differences, exclude the possibility of leveraging a particular platform's strengths, and target the lowest (i.e., worst) common denominator. Sometimes that's a good tradeoff! But _all_ the time? To the point where we have to attack OS vendors for having the nerve to, oh gosh, add a feature?

Taken to the extreme, this makes no sense. What's the point of even having different operating systems if there's only one acceptable API? Do you guys think operating systems can never be allowed to introduce a feature and corresponding API call?

<comment><USER12> I think it's inexperience speaking, which is also why it's very dogmatic. If you've seen how standards develop, they're usually taking many ideas like this that have become popular and tweaking the specs to smooth out the differences.

The POSIX API is often called Berkley Sockets because a vendor, BSD, released their API and it was widely adopted. ANSI C cobbled together existing C compilers into a standard, and POSIX itself was trying to tame a huge mess of Unices.

And even if the standards don't fully converge, you have standard libraries to plaster over the differences. Everyone has to contend with weird Windows path conventions and such, to the point where it's hardly even notable.

</comment></comment><comment><USER13> See also the Network.framework-based netcat implementation [1]. Only a couple hundred lines of code, complete with TLS and mDNS support.

[1] [https://developer.apple.com/documentation/network/implementi...](https://developer.apple.com/documentation/network/implementing_netcat_with_network_framework)

</comment><comment><USER14> I wonder how this can/will affect Go's standard net package [0]. Will it be able to take advantage of this new Network framework (on macOS)? Or is the framework too high level for the low level primitives net exposes, and will need a new separate API?

Also, personally, I suspect this is another hint of an upcoming transition to ARM64-based Macs. They will only implement these new Apple-specific APIs, not the legacy/deprecated ones like OpenGL.

[0] [https://godoc.org/net](https://godoc.org/net)

</comment><comment><USER15> Raw sockets have been discouraged in iOS years ago. It doesn't do things like waking up the radio, activating the on-demand VPN; it performs poorly when the device is multihomed; and from the developer's perspective there is a lot more code that needs to be written to support simple things like supporting both IPv4 and IPv6 (with happy eyeballs etc). The writing has been on the wall for years. I will not be surprised if a few years down the road Apple completely removes the sockets API from iOS (though I'd be surprised if they do it on macOS). I'd say good riddance to this outdated API. Your traditional desktop and laptops can continue to use this legacy API for your traditional and cross-platform apps, but iOS as a mostly consumption platform has no need for it. Personally I'm glad that Apple is using the closed nature of the iOS platform to delete legacy baggage and experiment with newer saner APIs that meet the needs of the twenty first century.

I'd also say there's very little reason as a typical developer to write socket code; just use a library provided by the platform or your language. When's the last time you used the raw sockets API?

<comment><USER16> > Raw sockets

This is an established term for IP-level sockets, of SOCK_RAW protocol type. Probably not what you meant.

[http://man7.org/linux/man-pages/man7/raw.7.html](http://man7.org/linux/man- pages/man7/raw.7.html)

<comment><USER15> Yes I mean using the sockets API instead of a higher level API.

</comment></comment></comment><comment><USER17> This is a nice high-level API for (more) reliably handling networking, taking a fair amount of load off developers having to implement it themselves. Of course it would be nice to have an API like that available as cross-platform library.

<comment><USER18> What about ZMQ?

<comment><USER19> ZMQ is not a 'neutral carrier' and can't interoperate with things not implementing the protocol. It's great for the intended use case, but it's not a general purpose replacement for the Berkely Sockets API.

<comment><USER20> Maybe, but it works really well for most applications, and its available on almost every language you can use.

<comment><USER19> I agree - it's a great tool and useful for a lot of things. However, it's not useful as a general purpose network stack, which is what Network.framework is.

<comment><USER20> I saw it has a C API, if someone made bindings, that would be nice

</comment></comment></comment></comment></comment></comment><comment><USER21> Why does Apple have to make everything proprietary? It's kinda annoying.

<comment><AUTHOR> Like any other OS vendor you mean.

<comment><USER22> You mean "like one and only one other OS vendor"

<comment><AUTHOR> Like Microsoft, IBM, Oracle, Sony, Nintendo, Google, ARM, Green Hills, PTC, Unisys, DDC-I, MicroEJ, Blackberry, SAFERTOS, ....

<comment><USER23> To be fair, when it comes to sockets, pretty much every OS' interface is identical, all taken from BSD.

<comment><USER24> Most OS also have platform specific extension over standard apis. This is the same category. They will not(and can not) deprecate BSD socket. Posix and BSD socket are totally different from OpenGL/CL. It's just an additional api for one who want to have maximum control.

</comment></comment></comment></comment></comment></comment><comment><USER25> I'm still waiting for OpenTransport to take off...

<comment><USER26> Haha, nice. I immediately thought of OpenTransport when I saw the headline. I wonder how many developers actually wrote code directly against that API.

<comment><USER25> Outside of Apple? Probably not many directly. I do remember them sending out developer kits for it though.

</comment></comment></comment><comment><USER4> So will BSD sockets follow OpenGL's path to deprecation?

<comment><USER27> As long as Apple wants to keep macOS POSIX-compliant, the sockets remain.

[1] [https://images.apple.com/media/us/osx/2012/docs/OSX_for_UNIX...](https://images.apple.com/media/us/osx/2012/docs/OSX_for_UNIX_Users_TB_July2011.pdf)

<comment><USER28> From your link:

      * Open source UNIX foundation
      ** Support for multiple CPU and GPU cores via Grand Central Dispatch and OpenCL
      * Comprehensive UNIX user environment
      ** Standards-based graphics built on PDF (Quartz), OpenGL, and H.264 (QuickTime)

Your 2011/2012 document gives less assurance towards any future POSIX compliance.

</comment></comment></comment><comment><USER29> I love this! These are great ideas. Plans for more languages?

</comment><comment><USER30> Not open source, don't care. Open standards matter.

<comment><USER31> What's the point of this comment?

It's an Apple library for an Apple platform, to make things easier for people using Swift/Objective-C.

Some people care about that.

Just because it's not an open standard t shouldn't be discussed?

<comment><USER19> Unfortunately it seems that many people cannot distinguish between the programming model of sockets and the protocols that programming model exposes.

From what I can tell, Network.framework is a different API still talking TCP, UDP and so forth underneath.

</comment></comment></comment><comment><USER32> i do not understand what incentive there is for anyone to use this - <USER2> apple's deprecation of a standard they themselves conceived only 9 years ago [1]. Berkley sockets might not be the conceptually best approach, but their support is damn near universal.

[1] - [https://www.khronos.org/opencl/](https://www.khronos.org/opencl/)

<comment><USER33> There are thousands of developers who make the choice to write apps for only one platform. They now have a better networking library. What don't you get about that? Not everyone chooses to write cross-platform. For people who don't write cross-platform apps, why would they ever want to use sockets instead of this much easier to use API?

<comment><USER32> the cross platform bit was a little disingenuous of me. what i was really trying to say was that in 9 years time from now, apple could deprecate it at the drop of a hat. sockets, on the other hand, are likely not going anywhere, and also have the benefit of existing everywhere, as they have for a long time.

</comment></comment></comment><comment><USER34> You can use BSD sockets through the regular POSIX I/O API (read, write, select, etc.). I wonder if the same holds for Network.framework sockets and libdispatch I/O? Are they composable?

<comment><USER12> Network.framework seems to depend heavily on state notifications, which the POSIX API doesn't support.

<comment><USER34> I think you misunderstood my comment.

I was asking whether Network.framework sockets can be used via functions like "dispatch_read", analogously to how you can plug BSD sockets into POSIX I/O functions as file descriptors.

</comment></comment></comment><comment><USER35> Skeleton crew on OSX but they have time to reinvent sockets. Apple, 2018.

<comment><USER36> What makes you think nobody is working on macOS? I really feel that macOS got _more_ focus than iOS this year.

</comment></comment><comment><USER37> Let's see how long until they deprecate BSD sockets.

</comment><comment><USER38> Disingenious. A better way to say is that their particular socket implementation was inferior to their new proprietary API. There is nothing with socket paradigm as such that gives it inherent performance disadvantage.

<comment><USER39> I disagree. As discussed in the talk, Network.framework is built on top of their userspace networking stack. This eliminates the kernel-userspace context switch and gets rid of one packet copy operation. These are known problems in the socket paradigm, at least as it exists in Linux and every BSD.

<comment><USER40> Where do they say their network stack is userspace? I watched the video but the last 10 minutes and I missed it.

<comment><USER39> The userspace networking portion of the talk starts at 46:00.

To clarify, the whole networking stack isn't userspace. They still have the classical BSD networking stack. I think the userspace networking stack is used automatically by system libraries like URLSessions and this new Network.framework library. They introduced their userspace networking stack during last year's WWDC: [https://developer.apple.com/videos/play/wwdc2017/707](https://developer.apple.com/videos/play/wwdc2017/707)

<comment><USER40> Ah, good. Thank you.</comment></comment></comment></comment></comment>


'Microsoft Is Basically Malfunctioning,' Says A 20-Year Veteran Of The Company - <AUTHOR> http://www.businessinsider.com/microsoft-malfunctioning-joachim-kempin-2013-2

<comment><USER2> 1\. Leave one of the best known companies 10 years prior. 2\. Write book critical of company. 3\. Profit.

Found that missing post-collecting underwear point.

But, in all seriousness, MSFT has its challenges. However, it still brings in huge amounts of money and is dominant (though not as much as before) in a couple of major areas. It is a well known company and an easy target for many to criticize.

<comment><AUTHOR> Back in the 1980's IBM lost its way with personal computers, as Microsoft disrupted it with regard to its legacy systems. Looks like MS is in the same position now.

</comment></comment><comment><USER3> In the same argument he says MS should compete with FB and spin off the Xbox which is a "crummy product"? At any given time millions of people are on Xbox Live, they stay on it for hours at a time, and unlike FB people are paid subscribers to Xbox Live. If anything FB should be jealous of Xbox and Xbox Live. How many FB users would pay $7/month just for the service?

</comment><comment><AUTHOR> Essentially ...

The software giant is wrongly focused on competing with Apple by "pissing off its loyal hardware manufacturers" and releasing its own PC ...</comment>


How To Talk to Investors About Your Competitors - <AUTHOR> http://www.bothsidesofthetable.com/2010/12/26/talking-to-a-vc-about-your-competitors/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+BothSidesOfTheTable+%28Both+Sides+of+the+Table%29 <comment><USER2> Love this quote, a great reminder:

> Remember: being too early is the same as being wrong.</comment>


Ask HN: Why is there no buzz about Kensho? - <AUTHOR> I've read several interesting articles about Kensho,
 e.g https://www.nytimes.com/2016/02/28/magazine/the-robots-are-coming-for-wall-street.html.
Fortune has deemed Kensho as one of the top 5 most interesting Fintech companies. Yet every time a link has been submitted here there has been almost no activity.
They seem to be doing some interesting work, replacing a lot of the researchers on Wall Street.
Any thoughts? Anyone here work there? <comment><USER2> Hard to get excited about puff pieces. If they released some detailed info about their tech (seems unlikely) then that would probably draw some interest here.

I'd also take the "replacing a lot of researchers" with a pinch of salt. It's currently very wise to sell tech to Wall Street as a cost saver in addition to being a revenue generator. Flogging nebulous headcount reductions in N years where N is greater than the budget cycle is not exactly a novel technique.

As this article was written 18 months ago, I'd expect to be seeing significant reductions by now if their predictions are accurate. Unless Kensho is claiming credit for Brexit, the evidence seems to be lacking.

</comment><comment><USER3> Hi! Happy to answer any questions. We are also starting to ramp up our public technology presence by contributing more of our tools to open source and starting an engineering blog. [https://blog.kensho.com/latest](https://blog.kensho.com/latest)

Stay tuned for more updates over the summer.

Additionally, Kensho recently closed a $50m Series B from a consortium of the six largest global banks, as well as Google. We are growing rapidly (in Harvard Square, NYC and DC) and are looking for exceptional engineers to complete our team.

www.kensho.com/careers

</comment><comment><USER4> Maybe because --at the moment-- automatizing jobs is only profitable for very costly jobs, like those of traders.

Or maybe because companies are worry of those "glitches" that we see in financial industry (like yesterday) where hundreds of billions may disappear in a fraction of second.

Or maybe because it is easy to replace an employee that does not fit the job, but it is very difficult and costly to quickly find an alternative to a subpar automatized process costing hundred of millions.

</comment><comment><USER5> \- What they're doing is the norm.

\- Nobody knows about Kensho.</comment>


Why We're Shutting Off Our Comments  - <AUTHOR> http://www.popsci.com/science/article/2013-09/why-were-shutting-our-comments?MT7UQYG4ypbAP8LK.01

<comment><USER2> They should at least allow subscribers who have paying subscriptions to comment.</comment>


Ask HN: Why they are down? - <AUTHOR>

Recently, We saw facebook went down for couple of hours. Twitter goes down frequently. Few days back, Four Square went down. I was discussing this with my friend at office and realized, It is interesting to know how big applications fail (just for learning purpose though).<p>Do any of you remember of any such incident and can share the link that explains / describes how they went down. <comment><USER2> posted yesterday here: <http://news.ycombinator.com/item?id=1769761>

click the title to get the story - interesting stuff.

<comment><AUTHOR> Thanks Jason :)</comment></comment>


How Old Is Your Globe? - <AUTHOR> http://www.replogleglobes.com/howOldIsYourGlobe.php

<comment><USER2> A long time ago, I briefly had a girlfriend who was a geographer, and she impressed the hell out of me by casually looking at a globe in a library we were visiting, and telling me it was from 1923, just by looking at the borders and country names. Totally knocked me out.

<comment><USER3> Would you have known if she was wrong?

<comment><USER4> Bad form, old chap.

</comment></comment></comment><comment><USER5> This is surely one of the most beautiful sites I have seen in a long time. Of course, it would be nice if the period font were done in css3 rather than images, and if the interactive bits were html5 rather than flash, but putting technologies and trends aside, this is truly a pitch-perfect and whimsical site. Well done.

</comment><comment><USER6> @jfruh @mak120 and @lobster45. It's supposed to help you find the date of manufacture of a globe, not necessarily the date those changes in the names of countries happened, or to be a complete list of all the country name changes that happened.

<comment><USER7> More specifically, it's intended to help you find the date of manufacture of _one of their globes_.

The dates and country names reflect when Replogle Globes changed their products, not politics on the ground. The map is not the territory!

<comment><USER8> It isn't quite consistent even there. I have a Replogle globe that according to the chart is simultaneously post-1975 (with Suriname) and pre-1971 (no United Arab Emirates, Zaire, or Bangladesh). So I suspect the Suriname entry is an error in the chart.

<comment><USER9> Suriname existed as a separate country before it became independent in November 1975.

It was part of the kingdom of the Netherlands, but not part of the country itself.

It was called Suriname, at least in the Netherlands, and, I am fairly sure, in Suriname itself.

</comment></comment></comment></comment><comment><USER10> Bangladesh became independent in 1971 not 1972. And it was not formerly part of India, but was part of Pakistan. Makes me wonder what else is wrong in that chart.

<comment><USER11> It's not just independence, but international recognition. Croatia for example became independent in 1991, but got recognition from the UN, US, UK, Germany and Russia in 1992.

<comment><USER10> Bangladesh got recognition from the UK and several European countries in 1971 AFAIK. By December of 1971, even the armed conflict was over.

Actually, being off by one year isn't such a big deal. Most maps from the first half of 1971 would not show Bangladesh. But it lists Bangladesh as being previously of India before 1971. That is just wrong since it was part of Pakistan from 1947 to 1971.

</comment></comment></comment><comment><USER12> My globe has "Korea" (as one country) instead of "Chosen", so should be from > 1945\. On the other hand, it's in the same color as Japan. And it also has "Italian Somaliland" and "Abyssinia" instead of "Somalia" and "Ethiopia". So it could be from < 1941\. Given the size of Germany, and Finland bordering the Barents Sea, I think it's pre-WW2.

Complicating factor: the maker of my globe often uses two names in the period surrounding a name transition. Thailand is called "Thailand (SIAM)". The name in capitals is not necessarily an official name, because there's also a PAKISTAN, which is a post-WW2 development.

Confused.

<comment><USER13> Is Poland still present on your globe? Is Danzig still Polish territory? How about the Baltic states? Are they still independent? Is Albania the same colour as Italy? Where is the border between the Soviet Union and Romania? Is Slovakia on the map?

I have a wonderful globe from the same period myself, made in Berlin between April and September 1939.

<comment><USER12> * Poland exists (but is shifted eastwards), Danzig is Polish. (>1920)

* Bessarabia is part of Romania (<1940)

* Baltic states appear without SSR suffix, but then again, nothing carries an SSR suffix on this globe - though there is a USSR.

* Istria is to Austria (<1919)

* Czechoslovakia is on the map as one state ( >1918 )

* Albania appears to be a state, it has a different color from Italy. (probably < 1939).

Thanks for the hints. It is most likely an interbellum globe, but the Istria thing is bothersome. Maybe I should take a picture.

</comment></comment></comment><comment><USER14> Some of the comments are missing the point that the information in the chart is to be used for dating globes, which sometimes show place names for places before they change political status (e.g., gain independence after being United Nations trusteeships) or sometimes are published after a place name changed near the end of the previous calendar year.

</comment><comment><USER15> So why doesn't anyone make a "Forever Globe" that projects from the interior of the globe the image of the world onto the exterior of the globe? You could then update countries as you go, and even add things like the weather, etc.

<comment><USER14> Google Earth embodies the data management needed to make a forever globe, so now someone just has to make the suitable projector. I have long desired a globe that would interactively change its display to make, for example, population density or altitude or some other displayable feature more prominent than political boundaries.

<comment><USER15> SO, know anyone in China we could talk to about this? I suspect the trick is to find a way to create a curved touch-sensitive surface. I'm tempted to do a render and setup a Kickstarter for this, but I'd like to make sure that someone makes the basic parts before I start "taking orders". Surely there are some folks on here who can at least tell me who to talk to?

</comment></comment></comment><comment><USER16> What about South Sudan?

<comment><USER17> Beat me to the punch! Needs updating.

<comment><USER18> Not to mention Kosovo as well, perhaps.

<comment><USER17> Well, usually globes tend not to put countries on the map until they're universally recognized. Kosovo's an interesting edge case though!

</comment></comment></comment></comment><comment><USER19> For the record, Serbia and Montenegro didn't become just Montenegro; it split into two countries, Serbia AND Montenegro.

</comment><comment><USER20>
       New Name:    Republic of the Union of Myanmar
       Date:        1989
       Former Name: Burma
       Location:    SW of China

<http://en.wikipedia.org/wiki/Myanmar>

<comment><USER21> That is the first thing I looked for, too. Whoever made the list must not watch enough Seinfeld[1].

[1]<http://www.youtube.com/watch?v=vAlinvw2Rb0>

</comment></comment><comment><USER17> It's also missing Palau (became independent from US trusteeship in 1994).

</comment><comment><USER18> List fails to mention countries that no longer exist, as they are now parts of other countries. Where's Tannu Tuva?

</comment><comment><USER22> As far as I know, Indonesia and East Timor are two different countries.

<comment><USER23> They are. The region which is now the coutry called East Timor was formerly part of Indonesia.

</comment></comment><comment><USER24> this supposes that your Globe is of planet Earth. What if it isn't?

</comment><comment><USER25> Not nearly old enough for the globe I have at home that's between 1906 - 1916.

</comment><comment><USER26> New Name : Israel, Old Name : Palestine. Date: 1948. The biggest steal of the century.

</comment><comment><USER26> New Name : Israel, Old Name : Palestine. Date: 1948. The biggest steal of the century.

<comment><USER26> Whoever didn't like my sentence is admitting that it's true.

<comment><USER27> No, its just that kind of comment doesn't really belong on HN.</comment></comment></comment>


Buying a dildo in Denver? government must be informed - <AUTHOR> http://www.theregister.co.uk/2016/12/13/us_purchase_government_spying/ <comment><USER2> The idea is that the government wants its fair part of tax.

But considering how all collected data in the US somehow ends up being able to be accessed by any and all departments that want it...

How long before purchasing a watch, an Arduino and a gun will result in SWAT kicking in your door?

<comment><USER3> People have been killed by police for much less.

The question is how long it is before it's no longer newsworthy that "police shot and killed a suspected terrorist who had purchased the components necessary for a remotely fired gun; up next, how you can keep your children safe from these threats online".

</comment></comment><comment><USER4> [https://en.wikipedia.org/wiki/Commerce_Clause](https://en.wikipedia.org/wiki/Commerce_Clause)

Considering how broadly the federal government has interpreted this historically, arguably regulating far more than simple inter-state commerce, it seems like they could use this to outlaw this kind of activity.</comment>