201–210 of 239 posts
Earlier quoted context omitted.
That’s by design. Keeps the workforce young and insurance cheap.
Less cynically, it also increases the odds of finding good employees. A "bottom 5%" worker is statistically less likely to suddenly rise to the top of the pack than a new hire is to produce at that level initially. And, more cynically, that remains true even if there's significant measurement error in identifying that 5%.
Earlier quoted context omitted.
Even without mature technology, you want to shake down the new tech early to find out if it’s going to crumble around your shoulders at the worst possible moment. While Agile is not perfect for this kind of work, it does have a lot of facility in this area. Now if you could just get any two people to agree on what constitutes the last responsible moment... And with new tech you often have to do it first or do it bett…
So, just from observation, when developing new tech, there is always LAST to market advantage. MS was LAST to market. Google was LAST to market. Kubernetes was LAST to market. Apple was LAST to market (After MS and Palm). I think that Agile is good after the market is captured. But when developing the core tech (usually with no customers beside product managers and based on research), it might be too constraining.
The hardest part of working with really smart people is that they can rationalize pretty much anything. Worse still, if they have been on the project for years and you’re the new guy, you’re working from a deficit of knowledge and they’ve had plenty of time to cook up a “coherent but wrong” model of the universe. The only thing that saves a group like that is humility. Trying to see the system through the eyes of the…
https://en.wikipedia.org/wiki/It%27s_Over_9000%21
(I was just looking at your profile because I was wondering if you were Kee who worked for Apollo?)
This post feels a little disingenuous... First of all, it's not like most engineers at Google are working on Bigtable or Borg, with a "very simple interface and tons of hidden internal complexity". Plenty of them are working on normal consumer-facing products, the "software with a simple core and lots of customer visible features that are incrementally useful", although maybe that's not the hype people want to believ…
The hardest part of working with really smart people is that they can rationalize pretty much anything. Worse still, if they have been on the project for years and you’re the new guy, you’re working from a deficit of knowledge and they’ve had plenty of time to cook up a “coherent but wrong” model of the universe. The only thing that saves a group like that is humility. Trying to see the system through the eyes of the…
You probably know this, but a lot of studies back you up. Being smarter doesn't necessarily make you more likely to be right, but it makes you a hell of a lot better at rationalizing your position and persuading others. Also, that comment about the "old guy with an inferiority complex who sneaks one really profound comment in every meeting" really hit home. We have that guy on my team too. You have to wonder what's g…
> (...), but it makes you a hell of a lot better at rationalizing your position and persuading others.
My reading has said the opposite: smart people are far more likely to be right, but it does no good because the important thing is to be able to communicate
I personally think that it is all matter of risk. The risk of contract work (which is what the agile manifesto writers were facing most of their careers [they are all consultants), is building something that the customer do not want or did not intend do. The actual tech risk is very low (e.g. ruby on rails on postgres) since most of them use mature technology. In this case the agile manifesto make sense - I.e. we can…
Presupposing that there are years of feature work to be done, do you go with Agile, or waterfall?
Earlier quoted context omitted.
The problem, so to speak, is that companies are getting extremely data driven, and constantly need some form of metrics to evaluate their employees. This again can turn into a culture where doing what's expected is devalued to lowest score - because you have that system where there has to be bottom and top performers. And you sadly end up with a situation where workers are (almost) embellishing their projects to get…
My company insists each ticket in Jira have a time logged on it now. This is on top of story points. Everyone I know has pushed back on it, but I hope this isn't becoming a standard elsewhere.
It's handy for charging clients for development work specific to them.
> This type of innovation takes significant up-front design time, and working on components over longer than one week iterations. Because the projects have such simple external interfaces, and so much internal complexity, much of the work is not even visible to “customers”, so there is no way to write customer visible stories about it. This type of software takes 8–20 months to deliver the first working version to th…
> This type of innovation takes significant up-front design time, and working on components over longer than one week iterations. Because the projects have such simple external interfaces, and so much internal complexity, much of the work is not even visible to “customers”, so there is no way to write customer visible stories about it. This type of software takes 8–20 months to deliver the first working version to th…
If they had fired you, you could have taken your code and created a startup.
Earlier quoted context omitted.
Right. Everyone is using duck duck go , Proton mail and vimeo outside of HN.
Allo me on Google Messenger. Or was it Android Messenger? Anyway, my Duo handle is xxHangoutsDudexx. We start a Google Talk session later.