I found this on Twitter, but I don’t have a twitter account so I thought I’d bring it over here. It seems like a good fit for #discuss!
// De...
For further actions, you may consider blocking this person and/or reporting abuse
Some hot-takes:
Developers should understand that "hard" and "soft" skills are a false dichotomy. The skills some folks call "soft" - communication, cooperation, etc. - are the core skills necessary to any kind of collaborative work, including ours. If you can't effectively communicate with humans, you will never reach the top of your field.
Understanding business rules DOES matter. Coding a solution for a problem you don't understand is an uphill battle. When you're questioned about the issue you coded to, it can sometimes be embarrassing to admit you didn't understand the problem to begin with but you knew what the solution was. It's too easy sometimes to go in and change a value or an if statement without comprehending the surrounding issue, but it's difficult to defend it in the long run.
That experience or expertise in a specific domain of business or industry is more valuable than the ability to program. It's the 80/20 distribution again. For most developers, 20% of your programming output is unique code, while probably 80% of it is modeling the business domain into an established web framework.
Definitely this. Just by happenstance, I started getting experience in the GIS industry over the last couple years. Turns out there is this huge market demand for developers that have a background in web application development and experience with GIS.
As developers, we assume we craft our careers around the technologies we learn. In reality, our careers are crafted around the industries we inhabit along the way.
Style guides are so the code is consistent and easy to read. Not because spaces are actually any better/worse than tabs.
Refactoring is the process of changing code to make it easier to change (either in the immediate, near, or far future) without changing its current behavior. Refactoring is not "making the code pretty for pretty sake" or "getting it ready for code review."
Programming languages are tools; not religions.
The Blub Paradox is the answer to most programming language arguments/roasts/etc. It also applies to editors vs IDEs, Linux vs Windows vs Mac, OOP vs FP.
When I started my studies in CS, all our courses were meant to teach us concepts, paradigms, sometimes they would even involve an obscure language to force us to use a certain concept as there was no other way around.
At first I hated it, I wanted to build things, learn to make software and applications and all I was doing was some exercices. Now, with a step back I really appreciate what I learned and understand why the courses were built that way and I use it as a strength, I can easily switch tools and languages, all I need is to learn the syntax and the specificities.
I think it really depends on what you want, learning that way can kill your motivation but if you overcome it you will end up with a great adaptability.
I took Intro C++ as my first academic dive into programming and it almost ruined me lol
When building systems and applications, people don't care how you've done it; just that it works and they understand how to use it.
The project manager is important, and not just there to bug you.
A developer as the creator of a system is very different from the typical user of the system and might indeed be the most atypical kind of user there is.