morbidhawk

I was writing a small but semi algorithm-heavy library in C# that didn't rely much on other libraries. I later decided to port it to Java and realized that the more C#-like I had written the original code the harder it was to port. Later when trying to port it to JavaScript I ended up re-writing the C#/Java code to rely less on the standard libraries since each standard library differed so much. At that point my code started to look very procedural in the OO languages possibly similar to what you've been doing in Java.

I came to the realization I didn't even need a lot of the language features for what I was doing and decided to switch it to C to not have to maintain various versions of the library and it was a steep learning curve but I've come to really enjoy the simplicity but powerful capabilities of C.

My preference recently for side projects has been imperative/procedural style of programming. I prefer it to OO and FP hands down. To me code is so much easier to read when you don't have clever abstractions everywhere, most code reads line by line and isn't trying to hide anything. I think there is a tradeoff between concise terse code you find in OO/FP that reuses other code vs the long step-by-step procedural code. For me personally I'd prefer longer code that is not reusing a bunch of other functions.

It's almost a weird paradox: OO/FP focuses on reusing code yet imperative/procedural code (ie: C) does not reuse code but is itself the most reusable code. You can't have your cake and eat it too I guess.

> I feel like I must find a work not related to computer science

I'm not sure if you've already tried this, but in addition to applying to jobs related to your side project I suggest applying to other jobs that have a lot more jobs available. My guess would be the number of jobs for mobile game dev might be limited and competitive and that would make it difficult when applying as a recent graduate. Web technologies whether for front-end or backend development are greatly in demand and are worth considering.

> iOS developers do not face a huge demand like they have seen years ago

This is an apt observation. The number of jobs are seriously lacking for Objc/Swift, I was lucky to do an internship in iOS but could never get into another interview after that for the bleak number of iOS jobs available that I applied to. I transitioned into .Net web development and I have been given a lot more opportunities since.

Also, Apple also has a way of creating a walled-garden for their developers. Some of the best practices back when I was an iOS dev involved Apple-specific technologies like AutoLayout constraints and CoreData which doesn't give as many marketable skills if applying to non-iOS jobs.

I second this. The whole .Net ecosystem is built really well on object-oriented design principles and I've learned a ton about how DI/IoC and SRP/ISP designs get implemented since switching to C#. Additionally Code Contracts are really fun to experiment with to help you be more thoughtful in learning design by contract. If design skills are important C# is a great language to use for it. The only thing that bothered me at first when I switched to C# was the use of PascalCase member methods, outside of that one nitpick I've been very satisfied, C# is a solid language.

Did you reply to the wrong thread? Your reply would make a whole lot more sense in a completely different context.

My son is a lot younger than yours with a different set of struggles (currently he's just preschool age) but he also appears to be completely normal to people who haven't spent a lot of time with him. He especially struggles with sensory processing and fine motor related tasks. We haven't got a firm diagnosis yet but hope to find out more from behavioral testing (neurological testing hasn't been able to give us any good answers yet) so he'll hopefully be able to qualify for disability. I'm also worried about my son's future, especially since a lot of people he might end up working with likely won't understand that just because he might not look like he has a disability doesn't mean he doesn't have one (I see this kind of ignorance all the time). Best of luck to you and your son, I wish I knew good answers to give you about these kind of struggles but this is still fairly new to me.

I agree that switching paradigms is not easy. The part that sounded like a joke and still sounds like a joke is downplaying the difficulty it is to learn OO abstractions and patterns. Even initially being taught them, does not mean you've really learned nor understood them well. When comparing it to something "elementary" I'd expect something simple like 13+4, not something as complicated as software design.

> OO abstractions and patterns OTOH, taught essentially in "elementary school" which possibly makes them seem easier to understand

What did I just read, you're joking right?

What if learning "how to study" is just a way to distract yourself from learning the material? Finding a learning process might sound more fun and creative, but more than likely it will be a big waste of time. Fortunately, what you'll be learning from your study work is more likely to be useful and more fact-based than learning how to study, which is primarily opinion-based.

If I was to create a study guide I wouldn't tell the student anything they should be doing, but rather ask questions that lead them back to their source material:

* What are you learning about currently?

* Why do you find it challenging?

* Why is it important?

* What is the general idea?

Learning by applying some memorization technique sounds boring to me, in comparison to curiosity-based learning using socratic/thoughtful questioning. Instead of responding to study work with a fight-or-flight response, asking questions allow you to break out of that fearful mindset and start to examine the topic and as you ask questions about it you'll start to find little bits of interesting knowledge in it.

I do a lot of back-end web service work and I really enjoy using unit test debugging, it's really fast and gives you a good clean starting point. The times that I have to hook up the debugger to the web server to debug against the website in the browser can be really frustrating and a lot more work especially since the client-side code will call out again to retry web api calls that took too long. I'm yet to find an effective way to debug in this way without deleting breakpoints that get hit and then assigning new ones (and who knows which call exactly I'm debugging but since the data is the same it usually doesn't matter). Does anyone have a better way to debug than the way I'm describing, I use Visual Studio and haven't found a way to easily limit it to just the first call attempt?

> junior developers which use the same hammer for every nail

This is what is weird about programming is that you only need to know a subset of things to build stuff so it gives a lot of Jr developers a false sense of know-how and confidence (I was like this for a long while). I think a willingness to own up to what you don't know and like you said "research what's the best way to do it, consult with senior developers" is a hard obstacle to get past. I wonder if this might make it hard for hiring managers to assess skill, jr devs are probably more likely to sell themselves as more than they are and mid devs might be more likely to admit what they don't know.