101–110 of 174 posts
I implement a few changes wherever I work: - Commit messages must include a ticket number (or a keyword like "hotfix"). This is enforced by a commit hook that's bundled with the project. - Ticket templates that encourage clear tickets. A ticket should always explain why it must be done. It should also contain enough information for any team member to judge its priority, or start work on it. - Any relevant discussion…
Earlier quoted context omitted.
I tried that - called it Tech Shorts (lightning talks) at small company. Found the largest issue was Passiveness in the engineering crowd. Ended up giving about 50% of the talks myself, not because I wanted to, but because there were so few people who were willing to step up and present. About 70% of the engineering team would attend (~50 people), so it was well received. Will try a new iteration next time. What made…
This doesn't surprise me at all. The intersection of engineers and public speakers is pretty tiny. It's not recreational; it's high pressure. You need to find something fun and laidback. Something low stakes, like a semi-weekly video game competition.
The pressure that people feel is mostly self imposed. Most of the time the audience is there to learn given they have a gap. Most people are projecting their fear onto the presenter. Unless you are an actual leader of an organization, you are just one of the team.
(I'm a reformed strong introvert)
Every time I start a new role, I write up detailed standard work for the processes and make notes of what can be improved. As time allows, I make those improvements. I also keep rough track of how long each update takes, so if I have 20 minutes before a meeting I can start and finish a task. This helps me on performance reviews because I can objectively say "I removed 1 FTE worth of report updating, creating ongoing cost savings".
The productivity gains are amazing. Over time, reports become fully automated. Logging improves, helping trace down errors. What used to be 8 hours per week of report updating becomes 20 minutes of validating data.
It's 10x easier to take a week off if your tasks are documented. I routinely write up a process then make another team member do it, so I can find the weakesses and fix them. This helps the bus number, and makes it easy for someone to cover for me if needed.
Earlier quoted context omitted.
I tried that - called it Tech Shorts (lightning talks) at small company. Found the largest issue was Passiveness in the engineering crowd. Ended up giving about 50% of the talks myself, not because I wanted to, but because there were so few people who were willing to step up and present. About 70% of the engineering team would attend (~50 people), so it was well received. Will try a new iteration next time. What made…
> Passiveness A lot more people have some degree of social anxiety than one might think, especially in IT. Lightning talks originate—and work well in—the sort of tech-bro workplaces where there’s an Xbox, foosball table, and bar in the breakroom. Half the “culture fit” criterion of hiring for those places is just an attempt to filter out potential hires with any amount of social anxiety; so the average level of it in…
What's the need to always being 100% right. There are very few situations where there is a 100% right solution. Most are optimized 80-90% for a particular problem set. Indicating that "within our context, we believe this is the best solution" goes a long way in creating that opportunity for discussion and deeper understand of either gaps in the context for the problem, or adjacent problems that may leverage the work.
I resigned.
It can be a hard choice, but one that sets an example for your colleagues: there are some situations which a person cannot abide ad infinitum.
If the situation pushed you so far as to resign, then you made an important choice.
For me it usually goes with:
1. Have people trust you by usually executing a big project. For me it went by executing very well small projects and getting bigger projects until you're implementing a very big and critical project with a team.
2. Once you have executed (1) people usually trust or know you. Then you can start talking with people across the entire organization asking what hurts the most, make some list of things that are interesting to tackle and who would be the stakeholders
3. Choose one from the list of (2) and do it (or try to sell the need for it)! More often than not it involves a lot of conversation, empathy, teaching.. for example, if you want to implement CI/CD then be ready to:
a. Sell the value of tests
b. Teach best practices for testing
c. Have a skeleton project that people can easily copy
d. Have some tools to easily set up a Ci/CD for a project following the structure of (c)
e. Adjust notifications and workflows
And.. you have Ci/CD for a group. Now do the same for all other groups. Now your company has CI/CD, yey! Pick another item from (2)
Earlier quoted context omitted.
I don't get paid to give tech presentations. Preparing for them would affect the work that I am responsible for. So giving tech presentations would ultimately make me look worse at my company. This explains the passiveness at my company.
This is my observation across several companies/teams. The options seem to be either sacrifice "real work" time to make a good presentation or make a half-ass presentation and have people criticize the low quality. Do people here think "no prep" presentations could work? Where it's agreed that nobody will do any prep but simply talk about something they're knowledgeable about? Or share their screen and walk through t…
Demo, deep dive/narrative on your work. Demonstrating something cool. It was clear the prep was not expected or needed, and it would be scrappy - just like lightning talks at conferences.
The exposure and sharing of ideas was critical.
We even had times where someone would suggest a topic during the meeting and someone would step up and do a deeper dive into it.
Understanding is all relative. You don't need to be an expert to know more than your peers. You just need to accept that your extra knowledge adds value. And be honest where your limits of understanding are.
It’s so much healthier to say “yes, I trust that you need what you say you need but I need more information to be able to help you.”
I'm a Dev Manager but started as a mid-senior developer at my current company (now about 350 people). We grew a lot by acquisition and one thing I noticed was many "cultural silos" that made it hard to build a shared, unifying identity. Myself and another developer worked to try and address this with a lot of small things focused on cutting across teams & groups: a book club-style bi-weekly discussion, "Tech Talks" f…