Hacker News Reader

Comment by tetek | Hacker News Reader

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

View on HN

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

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.

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.

I totally agree with this, providing your team is strong and motivated enough. As a contractor, this is usually the case for me, but definitely not always.

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

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)

On the other hand, being forced to write something up gives you extra time to think about what you're about to do. I've had many experiences when I was about to commit what I thought was a trivial change to the code, but then suddenly realized that it was going to break something.

Like all things in life it depends on the team and workflow. I have my PM’s make tickets because many times I am in the middle of a different feature or bug and don’t want to have to have the mental load of remembering what the issue was. Secondly I work with very solid PM’s who document the ticket very well and it saves me time having to reproducing the issue. My team does have a lot of tickets but we make it work for us and our process flow.

Some of us are lucky enough to not have a sprint planning flow, and we can have a lot of leeway how we plan our time, which doesn't require tickets.

You can create tickets for every small thing, but it might not be very efficient.

You can also just create 1 ticket with a bunch of small things.

The devs on my team are encouraged to move tickets around and plan their time however they want, but JIRA allows our product, design, dev, and qa teams to coordinate without being in the same room every day. It's just another form of async communication that helps us make sure we're shipping everything we promised, and fixing all critical bugs before the end of the week.

Yes, it's basically the same for us as well. And we do group together smaller things into one ticket often.

For us tickets are most important to track what gets included in releases and patches, and to tell QA to test our branches (and we almost always require QA to test our branches before they're merged).

> if it is worth doing, and it takes less than an hour -- just do it now

Huh... you've never had 10 things that are worth doing that take less than an hour? Or did you just line them up and work 10 hours that day?

Just do it now maybe works on small projects, but large projects that span multiple teams and stakeholders typically have enough little tasks to complete that “just do it” might be referring to 1 of 50 different things.

You need some way to prioritize and work against those priorities, typically measuring impact or some variation of ROI.

I have my own todo list independent of the bug tracker.

I think having a ticket also helps coordinate things if your working between global offices. Also, having a ticket helps others pickup if your out of the office. This has saved my team many times.

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

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

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.

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.

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.

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

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.

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

Just "don't bitch" period.

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

All existing code is bad code.

It also leads to (in excess), a not great work environment

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

You mean apart from code review?

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.

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

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

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.

What were they building, a todo app?

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.

Lots of QA people?

I think you're thinking too narrowly about what "testable" means. Everything can be made testable.

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.

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.

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

Reply on news.ycombinator.com