|
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.
|
|
|
|
|
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
