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))
The ISPF editor is actually more than decent. About 20 years ago my father was writing COBOL (on both AS/400, now iSeries, and PC) using SPFPC, an MS-DOS editor inspired by ISPF. The line command/primary command mechanism is really no more quirky than vi's movement and insert modes, and it makes a lot of sense for languages like COBOL.
SEU, the built in editor on the iSeries/IBM i, is however rather shitty. It does actually do some linting, but no syntax highlighting and the 5250 interface never really got improved as much as 3270, so its 24x80 or 27x132. Granted you're supposed to use an eclipse based IDE since SEU is no longer supported, but to just look at stuff really quick. A fast editor is preferred.
I think SEU is far better than you seem to giving it credit for. In fact, I used it for decades and my only real complaints about it started when IBM stopped actively maintaining it. Over the years I also tried using various other "modern" editors, only to eventually cast them aside as being too unstable, buggy, or just slow and clunky (like Eclipse). In fact, I can only recall one particular instance where using such an editor (Eclipse in this case) actually proved unquestionably advantageous over using SEU, but even then I quickly got annoyed at some of the stupid (IMO) implementation details of it.
When Java was first available on the AS/400 (ported by a man at IBM UK - I have forgotten his name), I tried to use SEU as my editor (me being a PC programmer). OMG worst experience ever.
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!