Comment by tharkun__ | Hacker News Reader

Comment by tharkun__ | Hacker News Reader

Parent Full thread

You did read the "while doing it" part, right?

Talk about it. Prolifically. Say that you have no problem working on "that thing" but that it's going to take more time, because you're unfamiliar with that language / library / service or whatever it is that would slow you down.

Then adjust your estimates. If you are working on something completely new that you know nothing about, put in "Spike" tickets to prototype things. Put larger estimates for the tasks themselves after for the "unknown unknowns". When you discover an unknown unknown that can be extracted as a new ticket from what you are currently working on, create a ticket for it to make that fact visible and adjust your current ticket to say it got extracted so nobody still expects your ticket to do it.

Tickets are not evil, tickets are protection for developers - create them and comment on them, explaining what is going on and what needs to be done. Most companies aren't really "evil" in that way. They just don't know better. If you do happen to be in one of the 'actually evil' ones, go find another company to work for. E.g. if developer are not allowed by process or actually prevented by the ticketing software from just creating tickets and moving things around as necessary: run. Don't walk. Run from that company.

The “while doing it” does not work if you don't have experience with similar language. If you don't believe me, try learning Rust while writing a server for your work.

Tickets are useless. Real tickets are unit tests that need to pass for the software to be ready for production.

Tickets cannot protect you, only Odin's switch statement on stack trace can protect developers from bad changes.

I will give you an example, you worked for a company and on a ticket, you wrote “this code works this specific way and should never be changed”. After 6 months, the company fires you and another senior developer takes your place. The new developer never read previous tickets because no one read old completed tickets, so no one will read the message you left, and they will change the code accidentally.

However, in Odin with unit tests and locking stack traces with switch statements, the code is really protected from these kinds of accidents.

    The “while doing it” does not work if you don't have experience with similar language. If you don't believe me, try learning Rust while writing a server for your work.

I can't try that unfortunately. I have tried to push trying Rust "for whatever next service we need" but nobody took me up on it :shrug:. That said, yes, many moons ago, probably about 25 years actually, I did have a job that paid me to learn how to write a TCP server in Perl that would take commands in a custom plain text protocol to do certain things. It was a drop-in replacement for the same thing written in C by some developer that long since had left the company and nobody knew how it worked or knew C. And no I did not know any C either, nor had I written any servers in Perl at that point (though to be fair I had used Perl to do some quick regex magic).

But I think I'm barking up the wrong tree here anyway, because you seem to be completely set in your thinking that nobody should need to know more than exactly one programming language and that should probably be Odin and that anyone thinking or saying anything else is just wrong. Well good luck to you getting paid and having fun. I definitely know that someone with your attitude towards learning and expanding ones horizon would not last long at my place.

    only Odin's switch statement on stack trace can protect developers from bad changes.

I mean, until here it was all "fun and games" but either you've also had fun here leading me with your little crusade or you actually believe this. But then I can't help you.

    on a ticket, you wrote “this code works this specific way and should never be changed”

Ah I see now. You misunderstood what I was saying about tickets and what they're good for. Ticket != (unit) tests! Tests are what describes how your software should behave.

What I was saying about tickets being protection is that they're protection against "the company" and process and being rushed all the time "because agile". Embrace them. Use them to your advantage. Someone gives you one ticket to do X and do it quickly but you don't know the library or service involved? Convert it into an Epic and extract 10 tickets including some prototyping in spikes.

    Odin with unit tests

s/Odin/Any compiled language with good typing/g ;)

You expand your knowledge in useless things like design patterns and frameworks. Odin will make this type of knowledge useless.

Making simple tickets to epic shows that the company does not have a software architecturer. It means that you create a monster application with full of technical debts left by junior. If CDD used in your company, nobody would ever be able to replace a ticket with an epic, because the architecturer would show you from where to start and what steps to take.

This really is something else. Now you are also a psychic. That's it. I'm out of here but feel free to keep living your dream with Odin. I'll stay here in the real world.

Reply on news.ycombinator.com