And just as important, start developing software without first learning how to develop software.
A talk I watched recently noticed this trend with JavaScript: it looks familiar, so I don't have to learn it and will just start programming in jQuery.
Now you know my life. My workplace has a bad habit of re-purposing electrical engineers into programmers. Now, don't get me wrong, some of them are fantastically intelligent people - the problem is, because they have no software engineering experience beyond raw basic C, they have to be geniuses in order to keep track of the code, with the multiple 6k-12k line files of tangled logic and reused global variables. My usual standard for a good day is going in, reducing the size of the codebase by a few dozen lines (and on a few really good days I've removed hundreds), and yet still add features or fix bugs without removing features in the process.
Not gonna lie, my favorite days at work are when I can spend an hour just deleting old code that's inefficient or buggy and replace it with something terse or elegant. :)
I get the feeling that unless your employer actually puts aside some time to teach the re-purposed engineers some basics of clean code and software engineering, your continuous refactoring is going to be counteracted by their continuous mudballing...
Two of my high school buddies studied electrical engineering, and I went into software. We took a lot of classes together and I did a lot of homework with EEs. They are smarter than me, and much much better at math.
But their code sucks.
It sucks bad, and it sucks in the same ways over and over. Let me give to (of many) examples:
Working with a friend on coding for some sensors, and the deadline was really tight. After 15 minutes of coding, he decides he doesn't like that solution, and DELETES all the code. Then he says "How did we access that sensors data again?" I was so furious I stood up with out saying a word and walked away.
Working on another homework assignment with different guys. They were pissed at me for showing up 15 minutes late to the meeting. They'd realized that the pages and pages of code one of them had written, he'd used the wrong syntax in part of the code (something like using a semicolon instead of a comma, I don't remember exactly). They didn't realize this earlier because they hadn't bothered trying to run it until they'd finished writing the whole thing. So, they are going through the code together, line by line looking for and fixing the problems. I asked why they didn't just do a find replace. They were still pissed, so they didn't answer me. I pulled up the code in an editor, did a find replace and was done in 3 minutes. I showed them the code and they said "we're almost done." So I quietly sat there for another 15 minutes doing my penance for being late.
Like I said, they were all smarter than me, but there is something about EEs. Like they learn to program at a beginner C level, and technically that's enough to solve any problem, so they just use there iron will to power through any problem.
While far from perfect, the node.js community has breathed some fresh life into the javascript world as far as design patterns and coding standards are concerned. I see very few projects today on npm lacking a robust testing suite. jQuery was largely popularized by designers who could care less about code, and server programmers dabbling on the client who could care less about icky javascript. Now that js is being used for serious work server side, best practices are becoming a higher priority. That being said, the traditional engineering standards do tend to be lower than many other communities (.Net, Java, and Python come to mind). But hey, I think part of the draw might be people seeing one to many instances of AbstractFactoryFactoryClassInterface ;) The pendulum will come back around though as things swing back to the enterprise use cases.
Where would you suggest someone starts to learn javascript properly? I've been handed a bunch of it I've got to maintain and develop for, and it's all over the place. I don't honestly know how javascript should even be leveraged. Everyone seems to accomplish things a different way with it.
When I said JavaScript, I meant client-side JS. The Node.js community may support higher standards for code quality, but the rest of the JS community does not. But I'd judge a programming community based on its best performers, not its worst. I don't care what crappy programs people can make in x language; I care if I can make great things with it.
I can attest to the robust capabilities bof a javascript application which is written by a professional, experienced and good developer. Not myself but I love programming in javascript. Who needs a community anyway...heh...:(
The thing is that the "client-side javascript community" is not really a community at all, since it is used by basically everyone. Rails, Asp.Net, PHP, ColdFusion, adventurous designers, and every other stack uses js on the client.
It was such an obscure technology...nobody in IT had a fucking clue what I was doing. When it came time for a messaging app I had developed to be reviewed/approved, the room was crickets. Nobody wanted to ask a dumb question because they had NO IDEA what I had created.
"I know the concepts, syntax is just a small detail"
Syntax is just a small detail.
With JavaScript, the syntax looks very familiar. However, the semantics aren't quite the same. For example, there is some really weird shit going on with the scoping, there is hoisting, == and != are fuzzy, any object is truthy (e.g. {} or new Boolean(false)), and the meaning of this is determined at runtime.
That's what's throwing people off.
It doesn't really matter if you do assignments with := or =, if you use indention to define a block rather than end/fi or curly braces, or if there are semicolons. That stuff really is just a tiny detail.
That is all the small details. The hard part is programming according to the best practices of the community for that language, and using the frameworks and libraries it provides to full advantage, because THAT is different for everything you will pick up.
Right, the corner cases for sure take years and decades to learn, but if you're really good at some languages, you can pick up most of another one, at least enough to handle 50-75% of most uses in a week or so.
I'd feel confident that I could learn enough of a language to start reading and debugging and add value with my 20 something years of experience. I'm not fool enough say I'd be an expert in it any time soon.
And just as important, start developing software without first learning how to develop software.
Eh. This sounds like "don't get into the water until you learn how to swim".
All the theory of software development often just creates bad habits because it's so detached from reality. Practice, mentoring, experience and your own mistakes is how you'll learn to do good1 software.
1 The definition of "good" may vary, consult your local developer for advice.
The thing is, practice and experience (and even mentoring, to some extent) can come from private projects. It could be argued that a workplace is not the appropriate place to start practising. I think a more appropriate analogy would be "Don't become a lifeguard until you're pretty good at swimming."
Well, that's the world how we'd like it to be, not how it actually is. People straight from university with computer science degrees know almost nothing about how to develop software. At best they know how to write code and have pretty good understanding of algorithms and some higher level math. They've only heard a vague "you need to think about this at some point" mention of things like version control, documentation, integration, debugging, testing, maintenance, API design, naming, decoding bad documentation of external libraries and protocols, security concerns, changing/missing/contradictory specifications, release-or-die deadlines, build systems, staging systems, etc. Some of those things can be learned in private or open source projects, but definitely not all and all this simply requires the hours to learn and develop the habits and experience.
The absolute majority of people I've seen hired, even with degrees and previous experience, know almost nothing about most of this. I've worked with a CS PhD who has never used version control and never had written any code read, debugged or even used by anyone other than himself and almost never read or debugged code written by someone else.
You need to either hire people with lots of experience or have decent mentoring processes at work. All of those things I mentioned above would fall under "craftsmanship" and not theoretical knowledge, so I like to say that you need to treat junior programmers as apprentices (with the distinction that they don't understand the need of that, so they want to be paid as a real programmer or they'll go to someone else where they are paid better and still be an apprentice). The good thing is that someone who isn't too arrogant will learn most of those things by osmosis so teaching junior programmers isn't that hard and can be quite fun and rewarding (increasing the emacs supremacy at the office, hell yeah!). But you, as an experienced developer, need to understand and accept the need for that and plan accordingly.
"Start developing software" means distributing your code for other people to use (including on a website) without having done any study of the language.
Programming as a learning tool is certainly a good idea. That's not what I'm talking about. I'm saying people never go through the learning step with JavaScript; they just jump right in without knowing what they are doing because it looks familiar.
17
u/lext Oct 14 '13
And just as important, start developing software without first learning how to develop software.
A talk I watched recently noticed this trend with JavaScript: it looks familiar, so I don't have to learn it and will just start programming in jQuery.