|
|
|
|
|
|
by resonious
538 days ago
|
|
|
I'm quite scared of being this. I tick a lot of the boxes: I have a good rep for being fast and management likes me quite a bit. And I definitely have spearheaded things that I've since been pulled away from. I try to counter balance all that by writing docs and sticking around though. I do my best to help those who work on the stuff I was involved with. |
|
|
If you got something working, and are available to answer an email explaining why you made a design decision, then you're already cleared of being a bad Pete.
Pete can't make the perfect product and he shouldn't try to. If it took 2 weeks to make management happy then its a problem you can do "right" in 1 or 2 months. A new dev needs to read up on the problem, what Pete did, what needs improvement, and maybe restart fresh to deliver. Good management knows this.
But a 2-week-delivered project is naturally bounded in scope, and its better off for being 'proven' than whatever OP imagined the right way to do it is.
There are only 3 cardinal sins. Don't destroy/overwrite an existing architecture, don't be a smart/dumb coder, don't do a months long Pete-style yolo project.