I have done a little bit of coding: macros, small programs, tool controllers. What kills me is that I can do 90% of what I need using other tools (excel, JMP, imageJ, matlab) and coding mostly makes things take longer. Most of the effort is plumbing: where are my files, what is the structure of the output, where is the file: the boilerplate stuff.

I usually know what I want and how, but it takes quite a bit to structure. Back in the day, labview+scripts/c were great. You could get to a point, and then extend as needed.

The other problem, of course, is finding meaningful problems to solve. Would I like to build a semiconductor process simator: yes, yes I would. Will I....not likely.

The hardest part I think is knowing that you should ignore all of the noise around different practices paradigms, and frameworks and focus on fundamentals. The best way is to look through and try to understand some very well written open source projects.

I feel like I stumbled on doing this but for many, I think they probably just bumble along building web apps and taking much longer than necessary to understand fundamentals. You have to expose yourself to high level professional code and absorb as much as you can from it otherwise you’re in danger of plateauing.

I'm inclined to agree - there's a lot of cargo-cult practices in software development and it's hard to know that it's often over-generalised until you deeply understand the core of programming, which is essentially just breaking down big problems into small forward steps.

I agree I came into Programming via the technical side and there middle out development was how I normally worked.

By that I mean work out how the core algorithmic parts first then interface to the lower level (normally experimental rigs) and finaly polish the interface

Yes, it took me two or three years to have any sort of valid opinion on TDD or SPA vs plain html and where each would be appropriate and in what quantity. Watching talks helped me a lot. Programmers really like giving talks.

I tried to learn to self code for a few years, but kept hitting wall of what to learn next.

After realizing I really wanted a chance to change careers, I decided to just do a second bachelor’s, basically to have a curriculum.

So far, I’ve learned more math than programming. The actual coding we do is greatly benefited by the self learning I did before, but my understanding of what’s going on in code is much higher. The other place I got stuck seems very natural for other people to move past with ease, but it was how to really solve problems with code. For me, I think the much deeper understanding from a school setting will set me up to better understand how to solve problems with code. (At least, I seem to be pretty good solving problems with accounting, my first degree, so I don’t think I lack inherent problem solving ability. This whole second bachelors is a bet that I am just missing deep enough understanding of the subject area to apply it to problem solving yet.)

Having done a bachelor/master in CS and taught a coding bootcamp, I only believe this to be partially true. It depends on what work you want to do as a programmer. For example, if you want to become a web dev at an average organization, then compiler construction knowledge isn't the most optimized way to spend your time. Yes, it'll add to your general programming knowledge, but it's better to spend the time to directly learn JavaScript, how to setup a project structure, devops tools like Docker and so on.

People that claim that such things aren't timeless are missing the fact that once you've seen enough tools that your underlying knowledge becomes deeper (and therefore timeless) as well.

What will happen though is that when you're doing your job is that you'll begin to notice that you miss certain fundamentals. At such point you know what you're missing, and you can immediately do targeted learning without doing a whole bachelor for it.

This whole story does pressupose that you know aprior what kind of developer you want to be, which is not an easy feat since it's a bit a chicken/egg problem (i.e. you need to know programming and have seen different flavors in order to better know what you want to become).

I did the self taught route and it's funny, like, I read a lot of books and kept trying to work on stuff but I'm not sure when exactly it came together for me. Just seems like I couldn't and then one day I could.

> how to really solve problems with code.

For me, it took me a long time to really understand where to begin. It wasn't that I couldn't solve a specific problem, like on leetcode. I didn't know how to go from scratch to building some kind of tool or application.

The solution for me ended up being just watching a ton of random tutorials to get something started, then taking the tutorial a totally different direction. That gave me some examples of what the entry point to the process was, and from there it was just an additive process until I got the desired behavior.

I learned about 8 years ago and I think the first, hardest part is grasping the fundamentals - firstly data structures and algorithms. Things like visualizing the storage of data types in variables and using them later. Things like when you create a variable you create an empty box and assigning something to that variable is like putting the variable in the box. A tool to be able to visualize what an array of tuples looks like as you write code to store values would be pretty neat for instance.

I think that first hurdle is the most important by far because once I crossed that it felt like I knew I was actually capable of being a software engineer. The next difficult jumps for me were grasping OO concepts like polymorphism and inheritance and learning functional programming. I also struggled with async style programming (first callbacks, then promises) as well as understanding contextual values such as Javascript’s this.

Honestly if I were advising someone, with apologies to Dijkstra, I'd tell them not to worry about the CS side of things until they could make programs. Way easier to approach that stuff as someone who already is comfortable with programming basics.

Well the whole "public static void main(String[] args)" thing took me about 8ish months to understand everything in just that statement.

JavaScript, jquery, json, and xml also were another hurdle. I lump them just because I was kinda learning them all at the same time. I was doing web stuff and one day i finally understood the difference between a scripting language and a compiled language. Suddenly understanding how to use the language became much easier for me.

Oop took me about 6 months of just java coding constantly. Then I got it and it really helped me at my internship.

Now my main struggle is LINQ expressions and streams.

> Well the whole "public static void main(String[] args)" thing took me about 8ish months to understand everything in just that statement.

Yeah, that's exactly what I mean about jargon. Even the idea that you have to hardcode what appears at first to be a string of magic words is not very accessible.

> JavaScript, jquery, json, and xml also were another hurdle.

Another area where things are made needlessly difficult - you really shouldn't have to worry about /how/ your data is being transferred (JSON/XML), just that you are in fact transferring it. JS versus jQuery is a bit more of a legitimate concern, but thinking about them in terms of their function rather than what they "are" (JS being general coding and jQuery being a tool for manipulating HTML/CSS) clears it up a big.

> Now my main struggle is LINQ expressions and streams.

I can't help with LINQ but I use streams all the time - what about them are you struggling with? Maybe I can help.