I never walked around the earth and I cannot think of 1 single reason for willing to do that. And although I'm not female I would still expect it to be a risky undertaking, for any living being.
When I first learned to code in TurboC some 30 years ago I used the IDE's step debugger for a while. Although a great tool for learning how your code executes line after line, I stopped using it after a short while because I found it to tedious and distracting to go through the code this way. Being able to set a breakpoint and see the actual value of something I can do in an instant with logging. I never use the browsers 'debug' tool, tried it once and got bored already..
IMAO the code I'm working on should live inside my head, that's the place where I construct and debug. Even when I'm new on a +100Kloc project, I'd still prefer to read through the code and figure out what's actually going on.
I see so many developers in the JS world spending soo much time and focus on all those tools; types, eslint, debuggers, testing, etc.. it makes me really suspicious about whether they have the actual skill to write a good codebase. I can only be convinced when my code would be buggy and theirs flawless, but I never see that, it's for some reason always the other way around! Just take a look at this project (a random pick) with all those (virtual) safeguards, result: over 3600 issues!!! https://github.com/Microsoft/TypeScript
I mean 3600+ issues, WTF!! And I should be using this tool to prevent issues in my software? Sometimes it feels like this entire industry is broken.
Some “safeguards,” eminently type systems (with algebraic types and inference if possible) I've slowly come to value a lot, especially when maintaining a codebase for an extended period of time.
But otherwise, I still prefer to reason over my code, with the aid of at most a few debug prints / logs. Breakpoints I only use very rarely. Other debugger features not at all.
But I remember it taking many years before I could build a complete working picture of the code I was writing (or reading) in my head. Before that, I was basically horsing around. Thankfully, that was around high school time. By the time I got into the industry, I already had that skill finely developed.
Nowadays, I don't think many fresh graduates have it, and yet the industry prefers hiring them, rather than more experienced (older) people. Go figure.
I think we do have a talent shortage, seriously, I see it all the time in the companies I work for. And if you run in an interview like the author describes, it is very likely that the interviewer just lacks talent and happens to be in that position, otherwise he or she would recognise the opportunity and go for a good deal.
But there are also good reasons why companies are often extremely careful hiring new staff. Many companies are desperately seeking the right dev's because they know that the wrong pick can cost them tons of money. The mess a wrong dev can create can do so much damage to the product while it often has to be released within a certain timeframe. I've seen a startup failing because of that.
> Many companies are desperately seeking the right dev's because they know that the wrong pick can cost them tons of money. The mess a wrong dev can create can do so much damage to the product while it often has to be released within a certain timeframe
That suggests problems in management and organization. Likely also with existing seniors and their communication with management. If not having developer causes less issues then hiring average one, then the company really needs to rethink their processes and onboarding.
Yes it is optional until it gets hard to find a job with typeless Ruby. And indeed split Ruby communities just as with Javascript. The bad thing is that static typing in dynamic languages is HOT, which means if you don't move over to the typed camp you will look old and stupid.
If anything, dynamically typed languages (without special tooling) is for super smart people or people who are lying to themselves/others about the limitations of the human mind.
But I personally wouldn't hire someone who maintained that dynamic typing produced as good results and was reasonable for an even mid-sized project. They've either never had a long running project or they've never dealt with a big enough code base at that point, or they're simply being dishonest or lack self awareness. None of those are good signals. Not having worked on a project that goes on for long enough is fine, but having opinions on software maintenance in that case is foolish.
I come from Assembly and C, now working in Javascript. One of the reasons I made the move to JS is dynamic typing, getting rid of that administrative pain and now being able to create stuff much faster. Even in large JS apps I hardly ever have type related bugs at all, and when I have one I fix it mostly within minutes, don't need an entirely different language and ecosystem for that.
Now the JS fanboys discovered and moved (from Coffeescript to Babel ESxx) to Typescript they apparently think that they can write beautiful and bugfree software just because of static type checking! Let them please move to C++ or whatever statically typed language and shoot themselves in the foot by making all those mistakes that have nothing to do with static type checking at all! Oh, and of course hitting the wall because they are missing their precious 'any' keyword!
I totally agree that type checking for dynamic languages should be done in the IDE, tooling. But static typing in the dynamic language world is a hype at the moment, so we'll have to go through a wave static type checking frenzy. For my work I look at horrible code bases, perfectly typed and strictly formatted by tslint..
I started using TypeScript back when it was 0.8, before it even had generics. Does that make me a fanboy? I have a project with about 45k SLOC of TypeScript (using Knockout.js for presentation). There is really no way I would maintain that same project without types.
> For my work I look at horrible code bases, perfectly typed and strictly formatted by tslint.
There is no language that can stop people from producing horrible code.
> There is really no way I would maintain that same project without types.
That's bold. Do you think no developer would be able to manage it without TS? In that case you must be a fanboy!
And honestly, are you not using 'any'? And do you think your app cannot crash because of a type error at runtime? And do you trust all the third party libraries you are using that they always provide you with consistent types, also during runtime? I ask this because most TS proponents live in some kind of dream.
I'm sure some developers would manage such a project without TS. Good for them. I wouldn't maintain it that way because:
1. I don't have the mental capacity to keep every single function's argument/return shape in my head, or to manually check it every time I make a change. Unit tests can't deliver 100% code coverage in practice.
2. Nor do I want to perform refactorings with stone age tools like s/setFoo/setBar/g. Setting up type information lets my IDE understand which calls to .push() deal with a native Array and which ones deal with my own class, so it can rename the latter ones when I ask. I can also use tools like "Find References" and avoid false positives.
3. I'm not a one-man-band. My coworkers need to deal with this project too, and new developers need to be introduced to it from time to time, and types serve as documentation and guard rails for them much better than jsdoc or regular comments. (This also serves as a significant barrier against using anything more esoteric like Elm, because nobody around would be familiar with it. TypeScript adds just enough syntax on top of regular JS to keep JS users comfortable.)
---
I do use `any` (and `unknown`), I have no doubts that an edge case can crash my app because I didn't validate something, and I never expect third-party code to work flawlessly whether it has types or not. Rejecting TS completely because "but run time loopholes" is throwing the baby out with the bathwater (or to put it in a more hyperbolic way, being an anti-vaxxer because vaccines are not 100% safe from side-effects). TS and types are an additional safety net/force multiplier†, not a silver bullet. (That said, what is a silver bullet? Because I'd sure like one.)
---
† Only applies to a project that has passed its initial rapid prototyping phase. During wild prototyping rides, types can indeed slow you down. But that's really the same debate as RDBMS vs NoSQL.
C/C++ doesn't really have much static typing to speak of. I don't think you are realizing the power of real statically type languages, such as Haskell, OCaml, or Scala.
Are you thinking of the way ints and chars (and floating-point types!) inter-convert? That is a weakness or convenience, but otherwise the typing is pretty strong.
In some way our brains doesn't seem to be wired for getting rich and famous, most people go very wrong. Being a good and intelligent human being is very different from having just a lot of money and luck.
> People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive.
Your thoughts seem to be very subjective. I hope you don't write your code as naive as you wrote this comment.
I code for over 30 years now. It has always been my desire to write beautiful code that reads well, scales well, has no bugs and performs good. Does this makes me a vain imposter and not capable? At this very moment I am working on a total rewrite of an unmanageable codebase that was written by a very 'productive' guy.
Any paradigm can be formalized to the point of perversion. I think that's what the OP meant when they said that the hallmark of that group is how they obsess about standards and processes. The existence of cowboy-style code such as the project you're currently dealing with does not necessarily mean that the "process-over-results" people are in the right. There are many factors to consider, including the structure of the organization you're writing the code for. I don't think it's naive advice to suggest that people spend less time listening to vain role models, instead of actively working on their own skills in order to make better judgements in the future, which brings us back to the point put forward in the article: the way to mastery is through practice.
I think you and the person you're replying to are closer in opinion about what it means to write good, professional code, then your comments are letting on.
How I take the article, and what I think most in this entire comment thread agree with, are the following principles:
[1] code quality IS important. I define 'code quality' here as how many bugs are introduced to do a given feature, how resilient this code base is to requests for additional features/changes, and how easy it is for new hires to grok it / for you to grok it after a few months have passed working on something else and you've lost familiarity.
[2] Whilst it is important, it is not the only concern. In fact, a shipping product is MORE important. That's not to say that code quality isn't important. Any project that has deplorable code quality even if it ships is in trouble.
[3] So far the most effective strategy for producing code with high quality, is experience (that's subjective; my opinion. But I bet you share it). The best way to get experience is to write lots of code. In fact, writing code of LOW code quality should help MORE: The 8th feature request that comes in that initially sounds like a job of a few hours that turns into a weeklong exercise in frustration with stapled onto the end of that process another week or two chasing bugs - and maybe you learn something about where you went wrong in your code that powered the initial shipping product. This sounds like a much better way to learn these lessons than reading a bunch of blogs and listening to a bunch of presentations theorising about what 'beautiful code' means.
[4] extremes are bad. This more or less is already concluded by #1-#3, though. However, the 'beauty' extremists tend to present, blog, and in general act like they hold all the answers, more than the cowboy extremists do. That's entirely subjective opinion, of course. It's just my experience, and yours may well be different. But _IF_ it is indeed true that you're far more likely to run into a beauty extremist than a cowboy extremist, then it stands to reason programmers who are irritated by extremists of any colour will tend to exaggerate somewhat more on the _other side_ of the beauty extremists.
In the end it's a pendulum, isn't it? A presentation or blog post that comes across as authored by a beauty extremist probably was a capable, 'well adjusted' (in the sense that they would agree that shipping code is at least as important, and experience is very important) – but decided to exaggerate a tad on the beauty side to address some perceived notion that the audience's balance was too far towards the cowboy end of the spectrum.
Enough of those kinds of presentations, and a few are bound to perceive that the pendulum has now swung too far out towards the beauty end, and start exaggerating the value of the cowboy end.
What I'm missing in this discussion is that, from my personal experience, people who are very result-oriented hardly ever write correct code. They tend to leave a trail of subtle, hard to find bugs (because foreseeing edge cases is one of hardest parts of programming and doesn't happen naturally while thinking about the happy-path) and poorly designed persistence structures (refactoring code is easy, but refactoring data is painful-to-impossible - you just can't retrospectively collect what you forgot to collect initially).
Of course both extremes are bad. I lean towards the perfectionist camp, so I actively seek to work with someone result-oriented. I've found this teaming to bring great results, where both my partner and myself end up happy with the outcome and fulfilled in ways neither of us would by ourselves (for me because I produce more givem the same time, and for them because they feel much more confident in the resulting programs - corroborated later by the much lower number of bugs found in them).
I know this is the case because I've been told many times by many different people (and most of them actively seek to work with me again afterwards if the opportunity arises).
I bought the latest version of the MBP with the 'fixed' keyboard last year September. I have sold it 2 months later because one of the keys didn't work well anymore, I had to push that key hard for it to respond. It is amazing that Apple seem to completely ignore all the issues with the new MBP..
Its only a paradox if you think its primary function is education.
Its primary function is the warehousing of children while adults work; and secondarily, filtering children according to ability for future work (ie., grading).
The content of the "lessons" could be anything, so long as it (1) keeps them occupied; and (2) differentiates according to cognitive ability -- ie., grades.
The primary and secondary functions almost totally constrain its auxiliary function of imparting useful skills to children -- which were it sincerely attempted would fundamentally undermine the school's ability to warehouse and grade them effectively.
For the content of the "lessons" being largely irrelevant, ask: what can anyone remember from their lessons at 14?
The answer is random with respect to the individual: I cannot predict what you will know. Really only fragments of trivia were acquired. This is the opposite situation of skill acquisition: if you are a practising plumber/doctor/programming, I can predict what you will know.
This test, predicting the knowledge/ability of a person who practices a skill, really defines successful education.
What can you predict a person knows after high school?
You might also look at "Discipline and Punish" or works to that effect to gain a socio-political perspective on the scheduling/routines/rituals of certain institutions.
It is no accident that a school closely resembles a prison. That is its primary function: to limit the behaviour of children, to discipline them into conforming with the scheduling of working life, to occupy their time.
When you are tutored (to play a piano, in mathematics, etc.) you are really acquiring a skill: to play a piano, etc.
Contrast those two environments.
Learning a skill requires an environment almost the opposite of a prison, it requires a patient and highly skilled tutor, and some attentive practice and engagement. (Infant/primary education is closer to tutoring than high school).
Imagine high school not starting until 14 at which point you spent 4 years with tutors: at most classes of 5 with skilled mentors that guided you through skilled practice. Consider the social environment: how you'd interact with peers, your relationship to your mentor, the hours you'd keep, how much practice you'd get.
Contrast this again with prison life within a school: the teacher is not a mentor, they are a master. An enemy largely. You and your peers are at war for attention and time.
Down-voted because as someone personally involved in my local school district, this overly cynical view does not reflect at all the actions or motivations of the people involved in primary education.
Let me preface this comment by saying: this isn't my view of primary education, but of secondary mostly. Primary education has undergone a lot of changes and it is increasingly effective at education.
However, yes, the motivations of the people involved in a system is often at-odds with the system they've got themselves involved in.
The teacher's motivation may be school's auxiliary function but their mental and physical energy is spent on its primary and secondary functions.
"For the sake of educating these children, I will sacrifice my effort/energy/time in disciplining them, in grading them, in differentiating them, and so on".
People need their motivations.
My aim is to describe the system not to describe the motivations of the people involved: the former is social anthropology; the latter is religion.
I can remember several teachers who really cared about helping the students learn, and who always tried to do their best for them. They'd even go beyond their official duties, e.g. I learned the basic concepts of trigonometry before I was officially allowed to learn them from an off-duty math teacher.
But despite them being personally good people, by accepting the job they bought into an oppressive system. If they tried to improve things too much they'd be fired. Existence of good teachers doesn't make the system as a whole good.
