HN user
I think what was missing here was lack of developer buy-in into the actual changes implemented, and making sure that they were reasonable and sustainable. Sounds to me like a blanket mandate was handed out without buy-in and also wasn't achievable, and the developers felt they had to work around it to get their real jobs done.
Is the membership subscription worth the cost?
a lot of it is hubris as well, they just assume that others will be able to understand it because it's easy and intuitive to them, and if others cannot understand it they must not be good developers
I think the reason why I've found 1:1's so effective is because of the recurring schedule. We're all busy people, and having a structured time to sit down and talk about things helps, even when we don't think it will initially. Yes, bringing up and resolving issues in real time is still key, but there are always things that slip because we have more pressing concerns or we just never found the right time to discuss the issue.
It's like having regular meetings with a mentor, coach, or even a counsellor. I find these meetings to be very useful because the discussion inevitably leads to revelations that I would otherwise not have thought of. Could they have been discovered ad-hoc? Some of them, maybe. But it would be a coin toss with the hundreds of other distractions and responsibilities tugging us from every direction. Even with my spouse, I've found that having regular meetings where we sit down and really talk about things has been extremely helpful.
That being said, everyone runs 1:1s differently and I've been on some really bad 1:1s that had no value or always ended with a negative, bitter taste in my mouth. I use it as an opportunity to connect personally and to provide coaching and mentoring towards their goals, especially when they align with company goals. I then poke and prod in a way to really get at what the other person is thinking and feeling, what they are struggling with, and ultimately what the root cause of the problems are. The key in my mind is to surface issues that would otherwise not be discussed, and normalize it. I then work diligently with them to make sure we're addressing those issues, and if I have action items to report back to them on how I've been able to make progress. 1:1s are definitely not the only way of approaching this, but the one I've found the most effective.
Granted, some individuals are very vocal and constantly raise and discuss issues outside of the 1:1s to the point where we don't need them as frequently. For them I just push out the schedule more and have them less frequently, or we just use the extra time to again, build that relationship.
Killing a pig to save a life of someone dying is very different than killing a pig so someone can have pork chops for dinner.
The question should be "does my standup provide enough value to the participants to be worth the time? Why or why not? Are there other ways in which we can provide this value?". There is no 1 size fits all solution. Some teams may not find any value in standups, so they should be removed. Some teams find it a valuable time to sync up as a team so they should be kept. Some teams adapt standups to add value in ways that were not originally intended.
All I see here are arguments around a one size fits all solutions. Be fluid. Observe, listen to your team, and adapt.
I've seen this interpreted by smart engineers in a counter-productive way, in that they believe their code is so good that none of it ever needs any comments and hence they never write them despite the fact that their code isn't all that clear. It's more hubris than anything.
Otherwise, there are many techniques you can use to make the code self-explanatory. I've taken a comment before and restructured the code to literally read like the comment.
Tribe (tribemgmt.com) | Vancouver, BC | Front-End, Back-End/FS, Azure DevOps, Mobile, SDET | On-Site or Remote (CAN/US)
Tribe is a property-tech company whose mission is to provide the most comprehensive suite of products and services for building and managing residential communities. Our vision is to change the way people experience community living, connect with their neighbours and interact with their homes. We are ramping up our team after a major round of funding which will also make us public.
Still working on the full job descriptions today but want everyone here to get the first crack at it: - Front-End (React + AngularJS, TypeScript)
- Back-End/FS (C#.Net, SQL Server, Azure)
- DevOps Engineer (CI/CD, TeamCity, Azure)
- Mobile (React Native, Objective-C, Swift, PWA)
- SDET (Selenium, WebDriver, JMeter, Cypress etc.)
- Product Manager (Property Management)
Send Resume to techjobs@tribemgmt.com and mention HN. Only those short-listed for interview will be contacted.
Regardless of whether one chooses to use ADRs or not, recording the factors that went into a major decision is a great practice which can help counter the tendency to use Resulting. That is, we have a tendency to judge whether or not a decision was sound based on the outcome, rather than all the factors and conditions that made up the decision at the time we were making it.
Some explanation as to why the opinion changed for or against would be nice.
I wonder what encryption and key based techniques can be used to verify the authenticity of audio and video records in the future.
This video states that a randomized controlled study needs to be conducted, otherwise nobody can claim that hydroxychloroquine works or does not work.
One of the greatest lies perpetuated in America is that billionaires should pay less taxes than the average person because one day, you too could be a billionaire, and you wouldn't want to become less of a billionaire because of taxes.
Would love to hear about your experience and why CQRS/ES failed those projects, and what type of technical complexities it introduced.
Caves and Commons. Have an area where people can go to work without interruption, and have a common area where people can work in an open space and collaborate. Don't anchor an individual to either space.
What you are referring to is the Monolith First approach: http://martinfowler.com/bliki/MonolithFirst.html. The key is to identify service boundaries early on and keep them relatively clean so that separating them into microservices at a later point is easier.
Like a shipment of weapons sent to a castle to help defend it from outside forces. Makes sense when the castle is occupied by the good guys, but when occupied by the bad guys (cancer) it only strengthens them.
It may not have been the work of NK, but it doesn't mean it wasn't sold to NK.