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.
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.
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.
I think I would actually really love this environment if executed in a healthy way. Lately I've become a big believer in embracing my environment in positive ways if possible. A few years ago I would have said no way, but I'm beginning to realize when I shut out others it's not as productive as I think it is. There is so much more to learn from others than myself and I think viewing those interactions as ways to learn instead of distractions would be the way to go. Then again put in that environment I might change my mind but I'd be curious to try that out.
I agree that it reads a lot better and if you have to scroll horizontally it reads a whole lot worse, as a C# dev I have to constantly scroll back and forth to read a particular code block. I'm pretty sure C# code would fail terribly at fitting within 80 chars w/ its long names and generic type declarations and everything being indented withing a namespace it'd practically be useless to try to edit C# code from a shell interface.
> Its verry dificult because you cant verify what people are thinking, you cant debug it and you cant start over -- you have to guess a lot
I think there is a way to verify what people are thinking and that would be by asking them questions. As you point out later it has to be genuine and not a clinical encounter, and I'd also add not a self-serving one. If you genuinely want to understand what they are saying you would then be very present in the conversation rather than just trying to hear what you think you want or don't want to hear (ie: "I've got to found out if he/she's going to abandon me or break my heart" is a self-serving interest and will eventually have the opposite effect), but trying to understand what they are saying because you are curious about them and hold them in high esteem will go a far way and asking questions that help you try to understand their point of view.
Too many people are trying to either narrate the relationship or are trying to serve their own self-interests and apply way too much meaning to each interaction and if instead they saw an encounter as an opportunity to learn rather than to try to have it mean something personally I think they'd find a whole lot more success.
I'm not extremely experienced in social interaction but I've had to learn to be to be able to communicate better with my wife and this is what I've learned, my self-centered motives have prevented me from learning so much more from others and using curiosity and questions has been super helpful in helping me to overcome social anxiety and relationship conflict fears.
tldr; let go of your ego (don't take things personally) and try to learn what other people are saying by asking them genuine questions (rather than trying to do all the talking, you learn more this way).
I agree with you, it's not acceptable (and that is an excellent analogy). Aren't content consumers also to blame here as well though? Viewers put up with it anyway. I'm surprised by top google search results that bring up click-bait junk that requires waiting for a page-full of ads to load and then requires that you click through 10 more pages before you even get to all the information you needed. I think this is an indication that the majority of people are willing to put up with it because otherwise those sites would have a high bounce-back rates and wouldn't have ranked so high.
Edit: I actually read the article and the author makes this point better than I could:
> The only solution is to unite in changing our behavior. We need to give website operators an ultimatum: Remove the modals, or we leave. And we need to make good on that promise. By closing the browser tab, we can let the bounce rate demand what we as users cannot.
I think its extremely hard to know what your true self is. Like you said about codependent culture, it seems that there is a great deal of unhealthy social conditioning to unwind in order to understand what "Being Yourself" really even looks like. For me I've struggled finding the balance between not allowing myself to be walked on (due to my codependent tendencies) and being able to be vulnerable and open to hearing criticism about myself. In my mind it has been a struggle to determine whether my thoughts are codependent or authentic.
"Just be yourself" is a little too simplified I'm afraid, my former self was people-pleasing and constantly seeking validation while avoiding emotions and conflict, not being vulnerable. That is not the person I want to be, to discover who I am I've had to recognize that there are new values that were deep inside me (authenticity, vulnerability, honesty) but that I had to dismantle a whole bunch of socially conditioned lies to get there as I had a misunderstanding of those values. I don't think I could have done this process alone, therapy has helped me a lot to recognize that I had unhealthy opinions.
I still think the 2 are more related than they appear to be. I saw a comment on programming reddit (in regards to this same article) about how developers use constructive thinking whereas testers use desctructive thinking and it is a separate mindset, but I don't know that I agree with that as destruction kind of leads to construction, maybe developers could also benefit more with destructive thinking as well.
Take for example Socrates, he went around asking questions that would contradict people's arguments by destructively questioning a particular definition that was presented, but his purpose in doing so was to construct a better definition of whatever thing he thought was ill-defined. Each time a contradition happened a more well-defined definition was able to be produced
I wish I could get to the bottom of this. I've seen all kinds of arguments for and against whether or not to unit test and how much / when unit testing should happen. I haven't been able to figure it out yet.
- I heard it mentioned before code reviews found more bugs in an experiment more than unit testing did (I heard this study was mentioned in Code Complete but I haven't checked the source on this). I wonder if reading code catches more bugs than writing code wouldn't this be an argument for spending more time reading our code rather than writing code that tries to understand it?
- Unit testing has the added benefit that when you change existing code or refactor you know that the behavioral unit tests guarantee those same behaviors happen after refactoring (my first point above doesn't give the same benefit so this may be worth a lot more than finding bugs in code reviewing new code (as it isn't reasonable to read all the existing code over again).
- I've also heard that code coverage is a terrible metric and can cause bad unit test practices, trying to cover all lines of codes instead of trying to test for specific behaviors.
- Some unit tests may become irrelevant as the design changes and also have maintenance costs
Since my team does unit testing while striving for 100% test coverage of our back-end web service code, we put a lot of time into unit testing (quality of the unit tests might be questionable sometimes as we aren't testing for all behaviors only ensuring all code is covered), so I wonder if we spent all the time that we spend unit testing and instead would read over all the code areas affected by the new code we and other teammates are writing to ensure we understand how it works, would it be more beneficial to read the code than to unit test it? I'm not convinced either way myself
So as you say good testers are really good at breaking things, so what makes a developer really good? Maybe there is a related skill seeing testing and developing are related (testers test/break what a developer builds). So then maybe a developer needs to be good at fixing what the tester breaks. Which would mean he lets go of his ego or pride in his own code and is able to accept that he/she writes flawed code and be really good at fixing or re-building it. I think it's been ruled out that developers are never going to always write the code correctly the first time (surely that can be a good goal to have, but not something to believe is going to actually happen) so maybe what sets apart a really good developer from a regular one is that he knows that his code is going to have flaws and is happy to hear about them so he can go fix them and improve and re-build his broken work.
Edit: another thought: maybe the developer should see his code as a problem rather than an answer so that he can constantly question it. Rather than being satisfied that something you wrote is now done or solved, instead you see it as something that has likely created new problems for you to be able to solve (Mark Manson said something insightful about this, how solutions don't really solve everything completely as it might solve 1 problem it always presents new problems/challenges)
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.