“Typically, being promoted up to the senior level is mostly based on gaining skills, demonstrating those, and delivering impact. However, above the senior engineer level, other factors come into play. … For example, your team might be busy shipping small, incremental features, that have little complexity, but decent business value. You almost certainly won’t be promoted beyond the senior level by just doing great work here.”#
<input type="number=">) has always been problematic. #You know those old “Hello world according to programmer skill” jokes that start with printf(“hello, world\n”) for a junior programmer and end with some convoluted Java OOP design pattern solution for senior software architect engineer? This is kind of like that.#
The most exciting things I heard about yesterday at Altitude London were QUIC and HTTP/3, BBR, TLS 1.3 and some of the exciting things that you can soon do on the edge with VCL.
Patrick McManus on TLS 1.3: “It includes a performance dessert to make the security vegetables go down better.”
Moving TLS negotiation to the edge is in itself a performance improvement.
Being prolific is not about time management. There are a limited number of hours in the day, and focusing on time management just makes us more aware of how many of those hours we waste. A better option is attention management: Prioritize the people and projects that matter, and it won’t matter how long anything takes.This reminds me of agreeing to a fixed scope: all emphasis is placed on delivering a set number of features irrespective of their value or quality. In fact, in this situation, the only thing that can give is quality. #
The computing historian Marie Hicks can’t stand it when people tout coding camps as a solution to technology’s gender problem. “I think these initiatives are well-meaning, but they totally misunderstand the problem. The pipeline is not the problem; the meritocracy is the problem. The idea that we’ll just stuff people into the pipeline assumes a meritocracy that does not exist.”#
How Superhuman built an engine to find product/market fit. Ask your early users: “how would you feel if you could no longer use the product?” Focus on the “very disappointed” group. These are your biggest proponents, they will tell you why your product is important.
This reminds me of finding a beachhead from Crossing the Chasm.
I also really liked this piece of advice:
Our next step was somewhat counterintuitive: we decided to politely pass over the feedback from users who would not be disappointed if they could no longer use the product.
This batch of not disappointed users should not impact your product strategy in any way. They’ll request distracting features, present ill-fitting use cases and probably be very vocal, all before they churn out and leave you with a mangled, muddled roadmap. As surprising or painful as it may seem, don’t act on their feedback — it will lead you astray on your quest for product/market fit.
Nine prototyping tools compared. Because none are perfect but choosing the right one matters.
Quora: What happens to older programmers? Some become managers, many keep coding, the answers are pretty good. Keep in mind that there’s hardly been many old programmers yet.
As an aside, I find Quora questions fascinating. The questions run from the practical to the existential (what’s the point of life?) to the polemic (don’t good programmers use ‘else’?; will PHP die out in 2017?).
There’s something both startling and amusing when someone asks: what are the best gems to be used with Ruby on Rails for a dating / social network website? — and receives candid answers! I appreciate the specificity, but that’s baldly a bold ask.
I suppose what’s most fascinating is what the questions say about us.
