Full-stack developer, currently work Tier 2 support at BlueSky Medical Staffing Software. Looking to move into a QA or software development position. I have a computer science degree from TNU. I code mostly with C#, C/C++, Python, JS and sometimes F# (for learning FP concepts). Hoping some day to become more familiar with Rust, Zig, and maybe Scala.
Safe systems are the best (because they don't suffer produtivity loses as often) and so I see TDD (or BDD) as the best approach in nearly every case. Tests are a matter of trust, which emphasizes the "science" part of CS which is that I should not have to blindly trust you - I should be able to see the proof and thereby know that the code is trustworthy.
Sometimes the error that we make is simply focusing on the wrong thing.
I recognize that supply-demand principles bear witness to the fact that being clever with code or making something more complex than it has to be means fewer developers will be able to work on the project and make improvments, meaning less available support for open-source projects and a small er talent pool for businesses. (Being overly clever can come off as boastful and with no apparent benefit.) What's important is that your tools are able to do all that you need them to do, and that your people know how to use the tool correctly. A good language makes it easy for the developer to fall into the the right solution for their use case. In my view, developers should for the most part be able to enjoy developing or else they might hate doing it after some time leading to a decrease in desire to develop over time (developers are people; psychology matters).
Experience is the best informant, experienced people are great advisors, and debugging skills are the evidence of a seasoned developer.
My preferred front-ends are Blazor or ReactJS. Backend for most things is ASP.NET. Extend your knowledge base everyday. Do something new and challenging that is useful on a regular basis. EF Core is very useful; I know SQL as well. Pardigms of programming can be useful for learning purposes but they should not be the "end" that we strive for. The best solutions usually incorporate elements from both competing modes of thought.
Other than lack of tools needed to build the best future, the thing in highest demand and least supply is developer feedback from actual users that are able to describe techincally what they like and don't like about tools/systems and why. What makes this in high-demand is how developers treat other people when they interact with those who are providing feedback. If you hurt your feedback loop, you eventually no longer have an effective feedback loop - yet this is all too common among developers: they can be unnecessarily mean sometimes.
It's always a good idea be return to the question "Why?" in everything you do to stick close to the meaningfulness of life, the universe, and everything. There is much meaning in building new things. Choosing to build communicates a hope in the future, that it can be better with the things we're building. The future is better when we build together.
Feel free to email me at collynbrenner@gmail.com to get in touch or send me an IM on X (formerly known as Twitter).