Back when I used be a junior fresh out of school, my senior used to say, when releasing a first version or a major version of any software, app or website always implement easy to fix bugs.

End users or clients, especially the ones that tasked you with the creation of it, will look for a bug until they find one, if it isn't one you will spent hours trying to figure it out, instead give them one.
You know how to fix it and the client is satisfied they found one.

To this day, i still do that, although mostly not even aware of it. Eg: I know that's a bug but i'll fix that when (not if, when) they complain about it.

I even find myself telling the juniors, i develop with, giving them similar if not the same advice.

And that is what experience means, skill is something they teach you in school.
Experience is what makes you a senior or a junior, not your level of skill or the amount of keywords on your Linked In profile.

  • 1
    I don't know about this. The client is going to find the bugs eventually. Seems like this is just kicking the can down the road.
  • 0
    @shittywebdev yes in theory, but there is this clause in the contract that gives us 30 days after release day to fix the any outstanding bugs as if it was still a project before it goes to our support channel, and then we just take all those bugs out, whenever they find them or not. Mostly those bugs are there in the pre-releases, when the people that tasked you with this or the ones paying for it, are the only ones that see it.

    And the bugs I'm talking about are things like having a red button instead of a green button and what not. Nothing that actually breaks the app, but visible enough that the client would consider it a bug. (or just something wrong, eg styling or a spelling mistake)
Add Comment