In my first year of university, I wrote a Java swing game which had classes for literally every part of the GUI (I was young, carefree and unwilling to yield on the principals of OO I'd been taught earlier in the year. I think it had somewhere in the region of 100 classes. Of which only about 3 had the real logic in them.
Now I've put it in perspective, I went on to an intern position between years 2 and 3 of uni. I was handed a lovely piece of code which had:
- Around 300 classes
- 3 or 4 layers of nested generics
- Factories, factory factories, generator factory factories
- 90% of the parameters were passed in from the build engine running the code, so it was impossible to run locally, ever.
- 0 tests
- Some 100 pages of documentation, which had been lost until I was about halfway through my placement (and mostly documented how to set up and run it, not how to maintain it)
Seriously, this thing was designed to the extreme, made to be generic to every single scenario in existence.
So what did it do? It took items from a customer facing system, transferred it onto the internal work tracking system. Then when they were updated in the modern system, mirrored the relevant updates back to the legacy.
The best part? Every time the internal work tracking system updated (once every 6 months), this thing broke horribly and it was practically impossible to fix. Even if you managed to set up stuff so you could work in a development environment, it still connected to the customer facing system, so you had to be incredibly careful what you did during testing.
It wasn't the biggest in terms of LOC, but it astounded me just how much effort (apparently the guy who wrote it squirreled away for a year to write it, then moved to Canada, and was famous in the department for having one too many beers during a outing to a local Indian) went into designing this behemoth.
Missed my favourite part of learning the mainframe: where the enter key is.
Return and enter and two different keys, but, on most modern systems, they perform a similar function. On z/OS Return moves down a line (similar to Tab, but ignoring all entries on the current line) and Enter actually sends to data off.
Once you get used to it, it's really no different to the Linux or Windows command lines. It's certainly dated, but that's what you get from running a system designed to be fully backwards compatible (with 24-bit, 31-bit and 64-bit addressing modes) that can continue to run software that's over 40 years old.
[For reference, the mainframe originally had 24-bit addressing. When IBM wanted to add 32-bit addressing, they found that people had been using the remaining byte to store other data, such as flags. So, to avoid breaking customer applications, the 32nd bit is used to identify whether the address is 24-bits or 31-bits]
((And yes, for the record, I am an IBMer, working in a z/OS product that's over 40 years old))
As someone who spent a few weeks looking at how the JVM really works, interfaces and super classes are not a compiler constraint but a JVM one. Sure, you could l could probably generate a lot of bytecode to get around this constraint. Or rewrite the specification for the JVM, and the JVM, and the compiler.
Frameworks like OSGi offer great exetensions to the humble on interface as well.
So, in my eyes, competency in programming isn't about knowing everything there is about programming. It's about finding knowledege. There's no shame in looking for similar problems on stack overflow (so long as you don't directly copy if you're in a place which that sort of things matters) and you slowly start to see patterns in your problems, which makes you look a lot smarter than you actually feel.
Unfortunately, you do need to get good at reading doc and code examples. Thankfully you generally get both, but not always.
Having some SysAdmin knowledge goes a long way; terminal command on Windows, Mac and Linux can be a real life saver when all the fancy GUI stuff fails.
The best way to get experience is to actually get involved in coding something medium to large. Its not easy just to jump in, but a lot of open source projects can have some very easy bugs to fix.
To help with recruitment, I add everything I can to github. Even if its bad code it will at least show improvement if you keep going with it (I still cringe at my first attempt at python).
A friend of mine wrote a book about getting hired (helpfully titled "Getting Hired") in the computing industry, it offers some great advice about the employability side of things: http://books.stuartherbert.com/getting-hired/
The choice of supervisor is pretty important, I was lucky and found one who held weekly meetings with all her students and who kept us all on track. She even pushed me to publish an academic paper (and a free trip to Italy to present it).
Now I've put it in perspective, I went on to an intern position between years 2 and 3 of uni. I was handed a lovely piece of code which had:
- Around 300 classes - 3 or 4 layers of nested generics - Factories, factory factories, generator factory factories - 90% of the parameters were passed in from the build engine running the code, so it was impossible to run locally, ever. - 0 tests - Some 100 pages of documentation, which had been lost until I was about halfway through my placement (and mostly documented how to set up and run it, not how to maintain it)
Seriously, this thing was designed to the extreme, made to be generic to every single scenario in existence.
So what did it do? It took items from a customer facing system, transferred it onto the internal work tracking system. Then when they were updated in the modern system, mirrored the relevant updates back to the legacy.
The best part? Every time the internal work tracking system updated (once every 6 months), this thing broke horribly and it was practically impossible to fix. Even if you managed to set up stuff so you could work in a development environment, it still connected to the customer facing system, so you had to be incredibly careful what you did during testing.
It wasn't the biggest in terms of LOC, but it astounded me just how much effort (apparently the guy who wrote it squirreled away for a year to write it, then moved to Canada, and was famous in the department for having one too many beers during a outing to a local Indian) went into designing this behemoth.
I still have the occasional nightmare about it!