21–30 of 155 posts
* Multidisciplinary
* Quantitative
* Scientific
* Curious, skeptical
* Thorough
* Willing to abandon a bad idea
* Willing to advocate a junior colleague's good idea
As an add-on question: Which of the properties mentioned in this thread do your organization actively drive out of people?
1. Don't bitch about legacy software 2. Are willing to help with getting proper requirements 3. Don't need a JIRA task for everything 4. Don't say they are done if something is untestable 5. Are willing to do stuff other than their skill (eg. one of the graphics required for the project is too big, top engineer opens up gimp, resizes and continue. Bad engineer will report to manager that design team did shitty job, r…
Bitching about legacy software is often necessary if you want something to change: pay off technical debt, additional time, migrate third party software to a newer version.
1. Don't bitch about legacy software 2. Are willing to help with getting proper requirements 3. Don't need a JIRA task for everything 4. Don't say they are done if something is untestable 5. Are willing to do stuff other than their skill (eg. one of the graphics required for the project is too big, top engineer opens up gimp, resizes and continue. Bad engineer will report to manager that design team did shitty job, r…
> 3. Don't need a JIRA task for everything Genuinely asking: how so? Tickets are not just some bit of bureaucracy, they are also a living log of what has been done and why that thing was done.
And as bonus points it can effectively prevent people from gobbling up only the work they want to do and leaving the shit for everyone else.
1. Don't bitch about legacy software 2. Are willing to help with getting proper requirements 3. Don't need a JIRA task for everything 4. Don't say they are done if something is untestable 5. Are willing to do stuff other than their skill (eg. one of the graphics required for the project is too big, top engineer opens up gimp, resizes and continue. Bad engineer will report to manager that design team did shitty job, r…
> 3. Don't need a JIRA task for everything Genuinely asking: how so? Tickets are not just some bit of bureaucracy, they are also a living log of what has been done and why that thing was done.
If you try for an hour and it's still not done -- make a ticket.
There's nothing more annoying than seeing the same trivial task get shuffled around 4 sprint planning meetings, taking mental overhead from 8 people.
And nothing comes out of sprint planning with less than a quarter day allocated. You've turned a 20-minute task into a whole day of wasted effort.
I don't care how good you are, if your personality is hostile and toxic, you're not making the team productive. If you can't take honest feedback during peer review, or QA or even from the client, then you need to evaluate why.
The best engineers I know are humble. They don't freak out when you point out a bug, they look into it and figure it out, then they share with you what they found vs what you found in order to determine if it is indeed a bug. Then there's developers that think all their code is perfect and sacred. Nobody likes working with those kind of developers.
Earlier quoted context omitted.
> 3. Don't need a JIRA task for everything Genuinely asking: how so? Tickets are not just some bit of bureaucracy, they are also a living log of what has been done and why that thing was done.
My personal heuristic: if it is worth doing, and it takes less than an hour -- just do it now. Organize your team so engineers feel free to knock off quick tasks at their discretion. If you try for an hour and it's still not done -- make a ticket. There's nothing more annoying than seeing the same trivial task get shuffled around 4 sprint planning meetings, taking mental overhead from 8 people. And nothing comes out…