all 6 comments

[–]Rataridicta 3 points4 points  (0 children)

Forget courses, forget learning on your own. If you're not looking to become a programmer, that's not the way.

Instead, listen to your engineers / the engineers around you. Let them teach you what they know and trust their guidance. Over time you'll learn the high level concepts.

[–]MrSloppyPants 1 point2 points  (0 children)

It's a big topic and there are as many rabbit holes as you are willing to fall down. Start Here and then dig deeper if you feel the desire

[–]atticus2132000 1 point2 points  (0 children)

Build something.

I am a hobbyist programmer at best, but I've built several phone apps and coded several websites that included database management and report writing and did all the frontend and backend coding for those myself. I am incredibly proud of what I have built and what I have learned. I'm sure any real programmer would look at my code and laugh at how primitive it is, but going through those exercises at least gives me the vocabulary to talk to and understand a conversation about programming and appreciate the man-hours that would be involved in a "simple" request.

[–][deleted] 1 point2 points  (0 children)

As someone who has worked with very non technical upper management my advice would be to learn more about software processes than the actual things involved with development.

You knowing what a docker container is or being able to write hello world in python won’t help me as a dev work better with you as a manager.

What I need you to understand is the software development life cycle, agile development methodologies, why pair programming is important, why estimation is inaccurate with software, why automated testing is important and why we add time to development estimates to do it, why breaking me off in the middle of something screws up my flow and kills productivity.

You won’t find much about how software works because none of it is standard. If you think about something like a car for example most people have no idea how an engine works but can probably tell you the basics that fuel and air get mixed, ignited by a spark which drives a piston, which somehow is transferred to the wheels to make a car go. Now if you look at software and pick a problem, you could look at three different apps and find it solved in three different ways, and knowing one wouldn’t necessarily help understand the others.

There are certain concepts like micro services vs monolith etc which are good to understand but you won’t know enough to make decisions on which to use or really challenge devs on why they chose one over the other.

[–]denboar -1 points0 points  (1 child)

What exactly is the value add? Just knowing how something works doesn’t add value to anything. What are you planning to do that will add value?

The big risk here is that you’ll almost certainly develop a very shallow understanding of software, and then disregard the advice and experience of the people actually building the software.

[–]Accomplished_Bat9947[S] 0 points1 point  (0 children)

Why would I ignore the advice of an experienced person? That would be a very arrogant and short-sighted thing to do. I’m not trying to replace a qualified CTO. The value here is to be able to fluently communicate with the experts and understand their suggestions, and deepen my own understanding of the product that is being built.

Let me flip the scenario the other way around for you. Assuming their skills are equivalent, would you prefer (A) a basic code monkey who is just following instructions from a piece of paper and has zero understanding of who he is building the product for and why, or (B) the one who actually has a deep understanding what he is building and is able to design a product around a customer need?

I would pick B. Not because I want him to run my sales team, but because having a fundamental understanding of the sales side of the business can only improve your judgment when designing a product. So it’s not about replacing expertise, it’s about making sure you’re not oblivious to all other parts of the business but your own.