recentpopularlog in

dev

« earlier   
Why everyone is talking about WebAssembly | Opensource.com
WebAssembly defines a portable binary code format for executable programs, a corresponding textual assembly language, and interfaces for facilitating interactions between such programs and their host environment. WebAssembly code runs within a low-level virtual machine that mimics the functionality of the many microprocessors upon which it can be run. Either through Just-In-Time (JIT) compilation or interpretation, the WebAssembly engine can perform at nearly the speed of code compiled for a native platform.
programming  javascript  dev  wasm 
yesterday by dstelow
Designing the most performant Row Level Security schema in Postgres
In an effort to write less application logic in my interfaces, (and out of pure laziness), I am persistently looking for performant strategies to bake access control directly into my schemas.
db  sql  security  dev  web 
2 days ago by flydown
Why do so many developers get DRY wrong? | Hacker News
This type of topic is hard to talk about. It's so nuanced that saying a statement about how to do it sounds like a a gutless generality. It also depends on the programming language and lifetime of the project. I've banged out some real ugly code when servers were on fire, but it was all stuff that was destined for an early death.
dev  dry  software  toread 
2 days ago by dano
Why Do Incompetent Managers Get Promoted? | Hacker News
I don’t agree with anything in this article. Incompetent managers get promoted because the things they are competent at are not the things their employees want them to be competent at. There is a dichotomy between traits that get people promoted at large companies and traits that make a good manager from the perspective of subordinates. Those traits only sometimes overlap. Thus the whole argument is predicated on a false definition of “incompetent”.

edit: people might ask, so here's a list of things that, in my experience, get people promoted at large companies:

politics, self-promotion, networking, choosing the right (high-visibility) things to work on, taking credit, delivering new revenue and/or new marketable shiny products/services, having the right senior leadership mentors/wing-people.

Note how none of these really require that a person be good at actually managing a team of people effectively.
.
Feel like you somehow managed to hit the nail on the head while also completely missing the point. Absolutely agree that often the things that get you promoted and the things that are considered compentency in a manager aren't necessarily the things that make a subordinate view someone as competent. But completely disagree on what those traits are.

In my experience, management tends to view favorably things like delivering on time, and on budget even if the product is compromised. Engineers tend to prefer taking longer and making it correct. Management loves accurate reporting, over communication and documenting. A lot of engineers tend to hate that stuff. Not all but a lot. A manager who isn't technical, or particularly personable but who does a good job of communicating up and out, and choosing high impact projects will do well. Even if they aren't exactly beloved by their direct reports
.
I think a key error people often make is assuming that the line engineers are always right. If a decision pisses off the line engineers it must be idiotic! The manager must be a fool. Peter principle in action.

This surely happens sometimes. But I’ve personally witnessed a lot of engineers (especially junior engineers) who don’t give a shit about customers or shipping products or building alignment or communicating planning and impact. And to have a successful team/product/company you will need to aggravate them sometimes and they’ll post things on medium about how their boss sucks and that nobody should ever estimate anything or how all tech debt is awful or whatever.

Good managers should support their team’s growth and careers, which should hopefully eliminate some of the “my manager is an idiot” stuff but it can’t eliminate all of it.
dev 
2 days ago by halonine
Product managers think in terms of problems, not solutions (2018) | Hacker News
At least on my teams, for example, user interviews are recorded and shared with the entire team, along with their raw notes, as are the high-level takeaways, allowing everyone to opt-in to as much or as little context as they'd like.
.
my focus is on honesty and making sure the team understands the problems we're looking to solve- and why. Sometimes that takes the form of "because my boss's boss says so, and we just gotta do it." I see my role as the PR person for the team
.
This doesn't work with every team. If they have a history of being blamed/battered by management for "failure" this approach is always rejected and the team wants detailed PRDs for CYA.
.
a lot of our stories were defined as "set a value on page foo, display it in table bar" without any context. This caused a lot of frustration on the engineering side because we didn't know why we were doing something, and were never given a chance to actually engineer something. It was compounded by the fact that these "solutions" were often reversed or made obsolete a month later by a new "solution" that could have been there from the start.

Thankfully, we've started having the real problems brought to the engineering side and work together with product management to come up with a solution. Yes, this means more meetings, but in the long run we're saving ourselves a ton of time un-doing work and avoiding traps in the code early on.

I firmly believe when you remove the "why" context from the conversation with engineering, you lose time and, more importantly, trust in the product team. I've not once come into contact with a product team/person who can accurately translate the "why" into the "how" seamlessly.

The most value I, as an engineer, get from the product team is their help in prioritizing work and coordinating across teams.
.
"Product Manager" means everything from project manager (organizer / scrum master) to client relations manager to product designer (like a game designer who isn't the programmer). This confusion is problematic.
dev 
2 days ago by halonine

Copy this bookmark:





to read