|
Foolish is our youth, and careless with words. 
I could give you an address where they always were looking for some confident young men to feed to their eldritch abomination. No matter how many years you try to understand that thing, you will always end up where you started from. Why? Because they went through all the motions, but with zero understanding. This thing has no architecture and everything is right there where someone thought it might be a good place for it. I think it has been put out of its misery by the customer by now and hopefully the company will follow.
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 see we fought the same battles.
War... war never changes.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
I could give you an address where they're always looking for some confident young men to feed their "fully dynamic best practices" application. No matter how many years you try to understand that thing, you will always end up where you started from. Why? Because they went through all the motions, but with zero understanding. This thing has no architecture and everything is right there where someone thought it might be a good place for it 
Hence my "unless", and even there I managed to get work done 
|
|
|
|
|
No, you will not. You are just lazy and too dumb to understand this masterpiece. They will try to suck out of you as much as they can and then out you go. If you want to go before they are done with you, then you are also ungrateful and unloyal.
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.
|
|
|
|
|
Sounds like they have more than one problem 
The "lead" programmer at the company where I worked got mad at me for touching his code (took 40 seconds, brought it down to 40 milliseconds).
He was only load because he spent the most time on the project and he had the biggest mouth.
Anyway, after I touched "his" code he made another "fix" and got it to 4 seconds, but according to him it was better than my code (it was an Entity Framework thing).
He also told me to rewrite a piece of JavaScript, which I wrote according to the Module pattern, but that was not how they worked so everything needed to be public.
And last, but not least, he was annoyed because I wrote some code that he couldn't even read.
I used a delegate... Go figure, the syntax was foreign to him.
He rather put everyone else on his level than learning from others.
Whenever I come across someone like that again I make sure to be gone asap.
Life is too short to deal with such people (and companies that let them).
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
