|
Isn't a delagate a respected senior diplomat, something like an ambassador?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
|
I had the same problem with my boss at one company. When he went off on a two-week driving tour of France his boss gave me permission to fix some problems in the code that I wasn't normally allowed to touch - it took me two days to get a real-time process that wasn't real time (188% of CPU calculated to produced real time response - so, obviously it didn't) down to 12% of CPU and therefore happily running at real-time rate. When he came back he went berserk and claimed I had "broken his code" and "ruined the architecture" despite that fact it now worked fine and the customers loved it.
He had made some basic errors, such as searching linearly, noting the index where he found what he was looking for but continuing the search to the end anyway! He also didn't cache the result (the indexes didn't change once the job started) so re-did the search on every sample - at 32 samples per second!
Luckily his boss stopped him from giving me any more sh*t about it but my annual review done by him was a joke! Once again, his boss overrode him and did my review himself - I got a raise. He got moved to "special projects" and was never seen again.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
More annoying than that is when you get dumped with a huge pile of KittyCode, get told the equivalent of "it don't work", and are expected to understand it all and fix it by the end of the week.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Don't forget having no support from the business side to help you understand what it should do.
Them: "This part doesn't work."
Me: "What does that mean?"
Them: "Well, it doesn't work."
Me: "Sigh."
|
|
|
|
|
Sander Rossel wrote: My manager at a former job was completely surprised that I was fully productive within a week of employment.
Well, depends on your role, I guess. When I start a new job, I make sure to fix a couple of bugs ASAP just to show that I can be useful, but it takes a while to understand what is going on there and even to catch up with the terminology. Unless I am given a completely new product to develop from scratch (never happened), it could easily take a year to be able to take over a complex software system.
|
|
|
|
|
How often do you have to "take over"?
I've always been part of a team, so when someone asks to fix the Flabrgam I can always ask someone what a Flabrgam is.
But a ctrl+find often does the trick as well
Just figure it out as you go.
|
|
|
|
|
Sander Rossel wrote: How often do you have to "take over"?
We are talking about new jobs, right? At my level, I am pretty much always expected to take over the responsibility for the project I get assigned to.
|
|
|
|
|
Very true. However, you know, we are smart guys.
|
|
|
|
|
Really, smart?
I've always considered myself brilliant
|
|
|
|
|
Smart is reductive, indeed: You're brilliant, I am a genius.
|
|
|
|
|
I wish I could claim that I am a genius. I tested 2 points shy. I blame the out-of-stock Coke machine.
Money makes the world go round ... but documentation moves the money.
|
|
|
|
|
Sander Rossel wrote: Just tell me which button to press, what the desired result is, and I'll dive into that code and have it fixed this afternoon.
Sure:
1. Dive into the button press that is on the front end.
2. Discover that it's being handled by some inane framework, in this case, ExtJS
3. Learn the minimum amount of ExtJS to figure out what controller the click is being routed to.
4. Look at code.
5. Discover it's calling the backend.
6. Recreate the AJAX call and start debugging the backend.
7. Discover after a few hours of wading through layers of ORM and custom SQL that the problem is 5 levels deep in some static update method that is generating custom SQL.
8. Dive into the custom SQL only to discover it has more holes than a worm farm.
9. Sigh.
|
|
|
|
|
But did it take you a year to find?
Also, could someone with plenty of experience with the code could've fixed it easier?
|
|
|
|
|
True... Until you are asked to fix a systemic problem.
I was new, excited, and a quick study. But I noticed a memory leak.
Upon looking into it, they used a reference counting system. But the children often referenced their parent, for access to related data.
They built a memory sieve! Nothing ever got freed up until the program reset. They had some hacks in there to free up entire objects, but they were failing because of the cyclical-references. On top of that, the design was chosen so that "data sets" could be "shared" between graphing and audio objects.
But wait for it... When you added these children to to the audio objects, they got confused as to who was referencing them, because they knew of only their "parent"...
I left it alone. It would have required a complete rewrite. Most users launched the application, measured something, analyzed it, and closed the program down. And if they didn't, the subsequent crashing from running out of memory would force them to! Nobody but me was complaining...
Yes, MOST of the other fixes were easy, as you describe. But they were not architectural in nature!
|
|
|
|
|
But as you said, someone who worked on the application for years or who wrote the whole thing couldn't fix it either
You understood the problem soon enough, didn't take you a year.
You also knew what had to be done to fix it.
But that was so much work no single person could've done it and no team could've done it within the time and budget constraints.
|
|
|
|
|
|
Indeed!
+1
|
|
|
|
|
that's the first thing I give up trying to learn about.
|
|
|
|