7 ms·

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 d

by tetek 7y ago

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, reassign JIRA ticket, write two emails and wait for new a graphic) 6. Top programmers deliver well packed, documented software, keep repository clean with easy setup steps accessible for everyone. 7. Top engineers enjoy what they do, and are making the project enjoyable for everyone, keep high morales and claim responsibility

codesternews 7y ago
Also, Don't bitch about other's code. You don't know in what constraints they have to write it.
- bobosha 7y ago
  Just "don't bitch" period.
  - masukomi 7y ago
    other than avoiding hurting people's feelings. why not? (honestly asking) bad code should be called out. It's reasonable to feel frustrated by bad to terrible decisions that your predecessors made and left you to clean up the consequences of. when a group of people is presented with a shitty situation verbally commiserating with your co-sufferers is a form of group therapy. Yes, it has to be tempered with hope and humor, but... bitching is good. Cynicism actually helps ward off burnout (barely, but it's one thing that contributes to warding it off).
    - haecceity 7y ago
      All existing code is bad code.
    - brianwawok 7y ago
      It also leads to (in excess), a not great work environment
    - around_here 7y ago
      “Bad code” is entirely subjective based on unclear standards. We had one engineer bitch about some solution that wasn’t “elegant” enough for him and he proceeded to waste 2 days “fixing” it.
- stinos 7y ago
  You mean apart from code review?
  - mceachen 7y ago
    There's a huge gap between bitching about bad code and coaching someone to refactor code into a good (or at least better) state. A code review is ideally the latter.
deleted 7y ago
[deleted]
FunnyLookinHat 7y ago
> Don't need a JIRA task for everything This! One hundred percent this! However, sometimes the sign of a senior is the ability to distinguish when something isn't a fire and should go through the proper channels... so maybe I'd also add: 8. Knows when a JIRA task should be necessary before starting work.
twoquestions 7y ago
> 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.) This kind of thing can be dangerous in the wrong sort of organization, be careful about stepping on other people's toes. What you call Bad engineering is adaptive behavior in an organization like this. Bad organizations incentivize bad behavior and punish good behavior.
- Cerium 7y ago
  I read this like "good engineers will unblock themselves with interdisciplinary action". I think the follow up on that example involves getting a resized asset from the UI team, but that should not hold up development and testing.
AllegedAlec 7y ago
> 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.
- thisone 7y ago
  I use tickets to offload my memory and ideas for later thought. 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.
- bpodgursky 7y ago
  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 of sprint planning with less than a quarter day allocated. You've turned a 20-minute task into a whole day of wasted effort.
  - AllegedAlec 7y ago
    > My personal heuristic: if it is worth doing, and it takes less than an hour -- just do it now. Sure, but that doesn't mean you can't create a ticket for it. It just means that you have tickets which fall outside your sprint planning flow.
    - bpodgursky 7y ago
      My point is that the overhead of writing up a ticket description becomes a significant fraction of the total work involved. Write a commit message if you want it documented. There's no need for a ticket for small tasks, unless you are being evaluated on number of tickets closed (which is a separate problem)
      - 7y ago
otagekki 7y ago
> 1. Don't bitch about legacy software 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.
- matthewmacleod 7y ago
  That’s a different thing, though. Proposals for change which are backed up by examination of the costs and benefits are welcome. Pointless complaints like “why are we still using PHP for this system, we should retire it” without any analysis of why is much more like “bitching”, is annoying, and something that I’ve noticed almost all less experienced developers do.
- masukomi 7y ago
  Agreed. I've spent most of my career cleaning up other people's messes. Bitching about legacy software a) makes it clear that the prior practices are not acceptable and can't continue (no tests, ignoring edge cases, ignoring users, all the standard stuff that makes up legacy code) b) helps keep you sane. The difference, which I hope the original author was alluding to, is that experienced dev accepts that legacy software is a part of life that has to be accepted, and dealt with, and that fixing it / keeping it on life support is frequently the right answer. Whereas junior's see it and run screaming or say there's no hope and it needs to be rewritten from scratch even though they don't really know the details of what "correct" behavior is.
  - around_here 7y ago
    You’re writing tomorrow’s legacy code today, so be kind about “other people’s messes” because you’re going to be the recipient of that same criticism one day.
aerovistae 7y ago
> Bad engineer will report to manager that design team did shitty job, reassign JIRA ticket, write two emails and wait for new a graphic I hate this sentence so much. "Bad engineer"? Being a good or bad engineer doesn't come down to a single thing, ever. A lot of organisations, like mine, which is a well known public entity, REQUIRE this sort of operational procedure.
- tetek 7y ago
  That was a poor choice of words from my side. Also, I have been writing this from my startup experience.
mtnGoat 7y ago
Many things are not testable. Not sure I'd use that as a reason to judge someone down. In fact all the most productive teams I've worked on or with, don't have anywhere near full test coverage. The best had none in fact.
- viklove 7y ago
  What were they building, a todo app?
  - mtnGoat 7y ago
    One of them is the web/system app that powers an Alexa top 10 site. Keep trying. ;) In fact I can think of at least 10 sites in the alexa top 100 that don't have any tests.
    - aledalgrande 7y ago
      Lots of QA people?
- icebraining 7y ago
  I think you're thinking too narrowly about what "testable" means. Everything can be made testable.
- tetek 7y ago
  It isn't about test coverage, it's about feature completeness. For eg. One feature require backend & frontend work, after a week of work engineer says that this is done. So you ask him to demo, and it turns out he is doing a backend demo with some dev tools. From a product perspective nothing has changed. Top engineers understand, that no one cares that only one part is working, they know the end user and will not bother managers/product owners with partial solutions.
  - mtnGoat 7y ago
    So you mean, it should work? Not sure I'd agree with that being a distinction among great programmers as much as a minimum bar of entry to call yourself one.
ailideex 7y ago
> 3. Don't need a JIRA task for everything Is this common outside of organizations where people are told to not work on anything that is not a JIRA task? And do people that do that not come mostly from such organizations?

by tetek 7y ago

codesternews 7y ago

Also, Don't bitch about other's code. You don't know in what constraints they have to write it.

bobosha 7y ago
Just "don't bitch" period.
- masukomi 7y ago
  other than avoiding hurting people's feelings. why not? (honestly asking) bad code should be called out. It's reasonable to feel frustrated by bad to terrible decisions that your predecessors made and left you to clean up the consequences of. when a group of people is presented with a shitty situation verbally commiserating with your co-sufferers is a form of group therapy. Yes, it has to be tempered with hope and humor, but... bitching is good. Cynicism actually helps ward off burnout (barely, but it's one thing that contributes to warding it off).
  - haecceity 7y ago
    All existing code is bad code.
  - brianwawok 7y ago
    It also leads to (in excess), a not great work environment
  - around_here 7y ago
    “Bad code” is entirely subjective based on unclear standards. We had one engineer bitch about some solution that wasn’t “elegant” enough for him and he proceeded to waste 2 days “fixing” it.
stinos 7y ago
You mean apart from code review?
- mceachen 7y ago
  There's a huge gap between bitching about bad code and coaching someone to refactor code into a good (or at least better) state. A code review is ideally the latter.

deleted 7y ago

[deleted]

FunnyLookinHat 7y ago

> Don't need a JIRA task for everything This! One hundred percent this! However, sometimes the sign of a senior is the ability to distinguish when something isn't a fire and should go through the proper channels... so maybe I'd also add: 8. Knows when a JIRA task should be necessary before starting work.

twoquestions 7y ago

> 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.) This kind of thing can be dangerous in the wrong sort of organization, be careful about stepping on other people's toes. What you call Bad engineering is adaptive behavior in an organization like this. Bad organizations incentivize bad behavior and punish good behavior.

Cerium 7y ago
I read this like "good engineers will unblock themselves with interdisciplinary action". I think the follow up on that example involves getting a resized asset from the UI team, but that should not hold up development and testing.

AllegedAlec 7y ago

> 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.

thisone 7y ago
I use tickets to offload my memory and ideas for later thought. 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.
bpodgursky 7y ago
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 of sprint planning with less than a quarter day allocated. You've turned a 20-minute task into a whole day of wasted effort.
- AllegedAlec 7y ago
  > My personal heuristic: if it is worth doing, and it takes less than an hour -- just do it now. Sure, but that doesn't mean you can't create a ticket for it. It just means that you have tickets which fall outside your sprint planning flow.
  - bpodgursky 7y ago
    My point is that the overhead of writing up a ticket description becomes a significant fraction of the total work involved. Write a commit message if you want it documented. There's no need for a ticket for small tasks, unless you are being evaluated on number of tickets closed (which is a separate problem)
    - 7y ago

otagekki 7y ago

> 1. Don't bitch about legacy software 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.

matthewmacleod 7y ago
That’s a different thing, though. Proposals for change which are backed up by examination of the costs and benefits are welcome. Pointless complaints like “why are we still using PHP for this system, we should retire it” without any analysis of why is much more like “bitching”, is annoying, and something that I’ve noticed almost all less experienced developers do.
masukomi 7y ago
Agreed. I've spent most of my career cleaning up other people's messes. Bitching about legacy software a) makes it clear that the prior practices are not acceptable and can't continue (no tests, ignoring edge cases, ignoring users, all the standard stuff that makes up legacy code) b) helps keep you sane. The difference, which I hope the original author was alluding to, is that experienced dev accepts that legacy software is a part of life that has to be accepted, and dealt with, and that fixing it / keeping it on life support is frequently the right answer. Whereas junior's see it and run screaming or say there's no hope and it needs to be rewritten from scratch even though they don't really know the details of what "correct" behavior is.
- around_here 7y ago
  You’re writing tomorrow’s legacy code today, so be kind about “other people’s messes” because you’re going to be the recipient of that same criticism one day.

aerovistae 7y ago

> Bad engineer will report to manager that design team did shitty job, reassign JIRA ticket, write two emails and wait for new a graphic I hate this sentence so much. "Bad engineer"? Being a good or bad engineer doesn't come down to a single thing, ever. A lot of organisations, like mine, which is a well known public entity, REQUIRE this sort of operational procedure.

tetek 7y ago
That was a poor choice of words from my side. Also, I have been writing this from my startup experience.

mtnGoat 7y ago

Many things are not testable. Not sure I'd use that as a reason to judge someone down. In fact all the most productive teams I've worked on or with, don't have anywhere near full test coverage. The best had none in fact.

viklove 7y ago
What were they building, a todo app?
- mtnGoat 7y ago
  One of them is the web/system app that powers an Alexa top 10 site. Keep trying. ;) In fact I can think of at least 10 sites in the alexa top 100 that don't have any tests.
  - aledalgrande 7y ago
    Lots of QA people?
icebraining 7y ago
I think you're thinking too narrowly about what "testable" means. Everything can be made testable.
tetek 7y ago
It isn't about test coverage, it's about feature completeness. For eg. One feature require backend & frontend work, after a week of work engineer says that this is done. So you ask him to demo, and it turns out he is doing a backend demo with some dev tools. From a product perspective nothing has changed. Top engineers understand, that no one cares that only one part is working, they know the end user and will not bother managers/product owners with partial solutions.
- mtnGoat 7y ago
  So you mean, it should work? Not sure I'd agree with that being a distinction among great programmers as much as a minimum bar of entry to call yourself one.

ailideex 7y ago

> 3. Don't need a JIRA task for everything Is this common outside of organizations where people are told to not work on anything that is not a JIRA task? And do people that do that not come mostly from such organizations?