Blah blah blah.
Gnome might try justify his case and just wander off into unproductive ranting.
Gnome is most likely wrong
gnome
Heavily edited to make more fun of me than anyone else
I also came from times when IDE's not existed. I remember punch cards as well And yes, I use simpler tools to code aswell, notably I write bash scripts in Notepad++ mostly out of habit. But efficiency is a key if you really aware of speed and productivity. Pretty much always. And I feel very gimped having only terminal and vim in my hands. It's just feels excruciatingly slow.
Also, you notion of 45mil lines of code - it's exactly the case when blazingly fast indexed search of IDE comes into play.
Also it's really question of quality of IDE. I personally found Eclipse/Coda/Netbeans to be very bad, but IntelliJ very good. You just need to try more stuff.
I never said this code was the best.
Hell half of it was written by Fortran folks that
really needed a Clue-By-four applied to them about certain language specifics ( 0 based VS 1 based ),
All of us are Guilty about this eventually. It happensPick a standard. those of us that support it afterwards will conform to it( maybe ).
Just that in a mature situation ( defined as, "well, it works" ) you can run into this anywhere.
Fortunately/Unfortunately you can run into situations where the people trying to figure out the logic ( be it code monkeys after the fact, or designers of the IDE )
do not have that built in biasIf you are working in a shop that does not have that kind of bias?
Great, you are ahead of the game.
But never assume that that assumptions by the
designers/implementers were the same as what you learned as the standard.
If the code predates you,
always double check the assumptions.
The newer methods are not
wrong.
They just stand the chance of having
nothing to do with the system you are tasked to support.
Language of the week ( Fortran/Cobol/C/Java/PHP/Eta al)
ANY of them can the job done. ( the only difference is where the issues come up )
It is the assumptions made on how things
should work that will bite you in the butt at the wrong moment.
IDEs are great.
The fact that they were written to conform to the standard, as apposed to what
really works is not a bad thing.
Maybe what I am trying to say in a less than perfect way is that you may look at it ( and have the compliler/IDE just
puke on it with warnings) does not mean that it is
wrong.
It might be absolute crap that is based on an older language that does not apply in this case.
Then again, it might be something that will blow your socks off with "How in the hell did they figure out this would work this well?"
The first case you put up with and try to fix over time.
The second case you sit back in awe over what was achieved.
Stare at it. Get confused as hell. Spend
weeks just wondering why it even worked at all.
Then the light dawns.
ooooohhhhh this is why this worksThe
subtle difference between complete crap and the most elegant code you will ever see is a very fine line.
It is recognizing where the line is that is the hard part.
Recognizing the three different things that will turn that wonderful code to complete crap is the next stage.
Writing that code that makes
everyone go "What? Does this even
work" is the final stage
Not that you should do this out of hand.
It is a very bad practice.
Since even
you will come back to it six months later and wonder why it works and what drugs you took to even design it in the first place.
It most likely makes sense at the time you wrote it, but hours of (no)sleep/Booze/Drug of the week have a lot to do with the mental state at the time you came up with it, and most of the time, those cases have nothing to do with
now. Sleep deprivation and massive coffee intake are much harder to reproduce than just outright doing anything else on a regular basis.
Basic design
evolves. the tools get better.
This is a
good thingBut
never assume that what came before is wrong.
It very well could be. It also might make sense in some weird way. ( not a good way, just a way )
Many of the long standing folks in software can be
pricks.
Unfortunately, the reason behind this may have
nothing to do with
you.
I've been on both sides of this.
Complete noob getting told off about some questions.
More senior person training someone up.
Unfortunately,in many cases, those that
know how things work get tasked with training the new hires, without any input on the hiring process.
If we( Seniors) are not complete assholes? Okay, we will explain it to you the first two times.
You could be good. You might be exactly what we are looking for, and we should want to get you to the point where you can be left alone. We really are looking for our replacements in larger companies.
Then we have the ones that are not well suited for the job. Could be the basic coding aspect, could be the abilty to grasp the overview of how the system functions, could be that they just do not give a damn to learn, If SRs care at this point, we will point out what we
think is the why.
Deal with more of the last sort and you get burned out on it.
Which is a failing on our parts, but it really is a case of self defense. Find the problem.( 90% of the time in several minutes just because we have screwed it up ourselves. Most of the more interesting mistakes are learned the hard way. Either we just outright screwed up, or had to fix a latent bug that predates even us, We can can learn from both ) Give the JR enough information to isolate and correct the issue without further input in a way that does not involve file name and line numbers. I.E
teach themIf they fail in this? Fix it anyway.
Work harder to get the JRs to understand
how to isolate the problem. ( and we never have instruction in this area. We all learn by screwing this up as well. Some are naturals. Some learn after a few screw up. Some are never good at it )
Problem solving, data analysis, and
confidence in the solution are some of the harder things to teach. ( Not just "I
think this is why it broke". knowing full well what caused it to break,
why the fix is correct, and the reasons that the fix should be installed now or after some testing. Let alone the confidence to state to a customer "
I[/]i broke it right here. This bit? garbage. Complete crap. It is the worst code ever written. But here is why I know it is crap, and why I have faith in the fix". If you cannot have this kind of conversation with the Customer ( and the flip side is being able to point out " Uh, you agreed to this" or "Uh, you stated it should work like this in this meeting on this date, why are we having this conversation???") without an issue, than making a mistake that an IDE or a context sensitive editor is the least of your problems]
IDE's are perfect for highlighting the basic mistakes of "Structure? what member are you even trying to reference?" that the compiler will puke on anyway. They save time there.
They do nothing to understand the side effects of what you just did to the data.
Nothing that gets complied can completely replace the human brain at this stage for problem analysis.
We are a few years off yet.
The day an AI system comes out that can do what I do?
I will retire,grow Hot Peppers for a living, be happier for it, and wonder why I did not switch over sooner.
I just do not really expect this to happen before I can retire anyway, and then spend most of my time pissing off the wife(more) instead of the customer.
Seniors can be the biggest assholes you will ever deal with.
Sometime we are so burned out with folks that never should have been hired, that we stop training our replacements properly, despite our own self interests. The better JRs are trained, the less we have to deal with during times that we would really rather be doing something else.
One clue is "Is this the first time I asked this question? Did I listen when taught?"
If this Senior is a prick every time?
It is the Senior. If you can find another mentor in the company, use them. No? Run like hell.
Is the Senior a prick after the second or third time the same question is asked?
Do most of the seniors react this way eventually( assuming more than one or two persons )?
Umm, it might not be them.
It could be you are not a fit for this area of work.
Various areas of CS have vastly different mindsets. some folks are very suited to one area and not another.
Some folks are really good at having tn thoughtless understanding of User Interfaces. They just do not have to think about it. They just know it is right.
Some folks understand data flow.
Some folks understand how to get data tofly[ in a slick way.
( I have done enough of all of this to know the difference. I suck at User interface. I know this, and try to fight anything that involves it. I will do it wrong without specifics. So if someone more suited is available? Get them to do it )
This is your target. What matches your skills/mindset?
Realize what you are good at. Working in that area will make you the most fulfilled.
Seek out jobs that leverage those strengths.
Computer Science is not hard.
Figuring out what part of CS you are the best at is the hard part. And then finding the Job to match that.
gnome