HN user

dberg

457 karma
Posts16
Comments135
View on HN

For example, an individual contributor software engineer s competency matrix may include a row for coding/feature output velocity. In a Level 1 to Level 5 system, the matrix would specify that for a Level 1 engineer, expectations on code velocity are X pull requests per week

I mean. No.

Atari 800XL Remake 3 years ago

dude, same! Got mine in 1985 (i was 9, not 8) and it was THE machine that got me hooked on computers. BASIC coding, playing Missile Command, so classic.

Hey all - Spent the last several months in quarantine building this on the side. I play a lot of poker with friends and we wanted a platform that worked on multiple devices and was geared towards private home leagues. Additionally I was annoyed by the pay models of pay chips, pay per hour or a ton of annoying advertising.

Zoker is a simple subscription fee for an unlimited amount of leagues/games/players. The idea is to have as much game flexibility as possible, make it easy to share information (like Zoom and Venmo) and keep stats/leaderboards.

Use Promo code HACKER90 for 90 days free to try. Please send feedback to info@zokerapp.com !

GitHub CLI 1.0 6 years ago

Is this proof that regular git commands are too difficult to use?

I also wonder what this is going to do for folks not using Github as now CLI users are going to "unlearn" all their traditional git commands.

After seeing so many Product Managers get this awfully wrong sometimes it also helps to understand what your job _isnt_

* Focus on outcomes over outputs. Your job is not to build a spreadsheet or JIRA backlog of features and then hand them to engineers to build like a coding factory. You do not have a crystal ball. You are not Steve Jobs.

* Involve the Business, Support and Eng parts of the org when defining _what_ to build. They all bring fantastic perspectives and really helps focus on the MVP and creates shared buy-in. Remember you are trying to solve a business problem not just crank out features aimlessly as a team.

* When mapping out _what_ to build, it always helps to use the collective team (in previous bullet) to outline Effort vs Impact. Forces really good discussion to keep things hyper focused and efficient.

* Instead of focusing on features focus on the strategy and the vision, let the team figure out how to get it there. As a PM you need to understand the market, the competitive landscape, how people are pricing their products, what customers are saying, industry trends, etc.

* Roadmaps in general are somewhat useless bc you don't have enough information and they create a lot of emotional commitments. Things change (hello Covid-19) and you don't know what you don't know. Instead outline your vision and strategy at a high level and make sure they are aligned to your overall business outcomes. This prevents people from saying "You said we would get feature X in Q2!!!". Instead you focus on metrics (Decreased Churn, Increase engagement by 3x, returning users more than X times in Y days, Revenue, etc).

* Be religious about data. Define your business outcomes, have good tools to track the progress of those outcomes, have a way to test/validate quickly and pivot as soon as it doesn't work. Keep fine tuning the machine

was surprised to see no mention of iHeartMedia (maybe news was too recent) which has an imminent Nasdaq direct listing on July 18th. Should be an interesting twist after Slack and Spotify given the stark difference in business types and growth numbers.

I met Joe in 2012 when I spoke at the Erlang Conf in SF. he is the reason I discovered functional programming and the whole concept of message passing (actor model) in distributed systems. Quite a legend and contributor to the world of computer science. RIP joe.