4 ms·

> I'm worried that node.js articles are the same kind of echo chamber that Rails articles were 10 ago. I tend to agree. > That, and nose.js developers seem to

> I'm worried that node.js articles are the same kind of echo chamber that Rails articles were 10 ago. I tend to agree. > That, and nose.js developers seem to repeat the claim that node.js makes delivery faster… The qualification was "if your team already knows JavaScript". OK... If the team already knows Java... building something like this in Java would be faster to deliver, and wouldn't hit some of those issues the author brought up (4 vs 1, single vs threaded, etc). And the whole "oh, you know language X" - means almost nothing when the project is more than trivial hello world. Every project I've been brought in on, the qualifier was "must know tech X". And almost always (there were exceptions) I knew more about tech X and software dev in general than the original developers, and the crunch was not "how do I do XYZ in this tech?" it was "how do I get the other developers to actually use version control?" or "use version control sanely?" or "document anything?" or "write tests" or "have test data" or "have a repeatable build process"? Knowing ASP or PHP or Ruby or whatever, but going in to a project without repeatable build process, tests, documentation, requirements or version control, is a recipe for disaster. Stressing the "deliver quickly" aspect of any language, if you're actually trying to deliver for a business or with a team of people, is extremely destructive short term thinking. And yes, sometimes, in rare cases, it may be a necessary evil, but I think it's become the norm with words like "agile" being thrown around as synonyms for "don't have to write anything down".

astinit 10y ago
As someone still studying and not in the workforce yet, are there really teams out there that don't use version control?
- Jackim 10y ago
  Yes. I have a friend who does QA for a major university and that department doesn't use source control at all.
- noir_lord 10y ago
  Yes, I used to do a fair amount of consulting (aka nothing works properly, fix it, have this bag of cash) and I frequently ran into 'projects' that had no source control or had <projectname>/1 <projectname>/2 <projectname>/2a_1_fix_foobar :|. One of the things you'll learn if you hang around Hacker News/online programming communities is that a lot of the people in those communities are at the top end of the spectrum (there is a degree of self-selection that means a higher proportion I think). It's pockets of relative sanity in a sea of disaster.
- hfsktr 10y ago
  Yes, my first job we have 3-5 devs at some points. We each had our own codebase (internal site, external site, console/windows apps). We never touched each others' code. Nobody ever set up source control for the code I had to work on and nobody but me ever worked on it, the others did have source control as far as I know and at least one had 2 people working at a time. We did try to get my using it but it was clunky and didn't last long since it was just me using it. It seems so strange in hindsight but that whole place was so so different from where I am now.
- the_af 10y ago
  Yes. Also, some huge multinational companies you're very likely to have heard of don't do automated testing of any kind, as least for non-critical software (source: my own experience). I'm not talking about TDD or any fancy agile technique; I mean any kind of automated testing whatsoever. If you're just out of university or read tech blogs or hackernews, you'd think everyone these days is doing TDD, pair programming and agile. The reality is that a lot of major businesses do none of that.
  - Pr3fix 10y ago
    Because in a lot of ways those practices don't further the end goal or bottom line of the business. They don't meet business needs. As a developer, I think we both can agree that these things make our (developer) lives easier, but they often don't help the bottom line of the company. I know some dev will retort this, but if I was wrong then companies would be mandating these practices top down.
    - mgkimsal 10y ago
      It's primarily perspective. I just came off a short term project which... yeah, it worked, but it's a disaster (but.. yeah, still working, technically). 4 years of no version control, no test environment for at least a year (it was shut down then never turned on again), no written docs, no written tests (and for periods of time, no backups). This software manages and controls 9 figures of USD annually. The 'bottom line' was/is always "i need a form that does X" and "I need a form/report to show Y". Yes, the immediate short term goals of the business worked. The entirety of the codebase has been hardcoded to work with library calls that were known tech-dead-ends years ago. The business now needs someone else to come in and manage things, because the original guy left. The business is now up a proverbial creek, because everything was in someone else's head. TDD/testing/docs externalizes some of that, and does have real business value, but it requires someone to be able to look more than 6 months in to the future with respect to tech decisions. Their bottom line will be hurt over the next year because they will be needing to pay far more to repair the tech debt, and it will mean fewer new things get done (or.. they'll pay even more for that). So... "business value" needs to be defined as to how you're measuring it, and 'short term' is always easier than 'long term'.
- nine_k 10y ago
  You have a chance to see all manners of known bad practices in the wild. It's important to recognize them as bad. It's also important to try to understand what lead to their adoption; often there are ways to work around that and apply a best practice in your area, even if other areas still suffer without it.
- Roboprog 10y ago
  Almost all teams these days that I know of have a revision / source / version control system of some kind purchased and installed. The "purchased" ones are usually worse than the open source ones (e.g. - Git, SVN et al). The "ENTERPRISE!!!" devs don't use the system effectively, usually: haul things off to a corner for weeks before doing a single check-in/commit; may or may not know how to branch; bumble with breakage during merge/pull operations; end-run the system by releasing non-compiled files directly to production without saving them in source control. Source control use is like the other comment about programming language: the main issue is not whether you have used brand X, but whether or not you have a coherent mental model of what the hell you are doing in the first place. That said, there are some BAD commercial source control systems out there, preying upon the "you need this, even/especially if you don't really know why" crowd. These are usually sold to The Management in terms of the control they bring to source control - they will have a trigger to force entry of a trouble/enhancement ticket to go with a check-in/commit. That fact that they suck at source management is of no consequence (e.g. - painfully slow, little to no command line interface for automation, poor research/discovery features, poor branch/merge support, unreliable / data corruption)
lordofmoria 10y ago
"Must know tech X" is exactly the mentality that we try to avoid in our company's hiring process. Most people would claim this makes your job descriptions too flexible, but the demand is actually incredibly specific: developers who can jump on a project in a tech they haven't "used" before and succeed 90% of the time. It's probably the case that only 10% of devs can do that comfortably though. Fits the criteria in 'Who' perfectly!
ekidd 10y ago
> Every project I've been brought in on, the qualifier was "must know tech X". And almost always (there were exceptions) I knew more about tech X and software dev in general than the original developers, and the crunch was not "how do I do XYZ in this tech?" it was "how do I get the other developers to actually use version control?" or "use version control sanely?" or "document anything?" or "write tests" or "have test data" or "have a repeatable build process"? I've seen this so many times on consulting gigs and with the occasional new employer. I'm hired because I'm familiar with the technologies they're trying to use, but the first major value I bring to the organization is simply getting some kind of sane process: working version control, automatic builds, test suites, one-button deploys, and so on.
- mi100hael 10y ago
  > I've seen this so many times on consulting gigs and with the occasional new employer. Same, and it's getting really fatiguing. Probably the #1 driver for me to get a side-project off the ground is to finally actually write code and not just play janitor for someone else's mess.
halisaurus 10y ago
> Stressing the "deliver quickly" aspect of any language, if you're actually trying to deliver for a business or with a team of people, is extremely destructive short term thinking. And yes, sometimes, in rare cases, it may be a necessary evil, but I think it's become the norm with words like "agile" being thrown around as synonyms for "don't have to write anything down". Unfortunately, this is pervasive in the "real world", especially with regard to client-driven (agency) work. Deadlines beat developers almost without fail. I agree that it is destructive short term thinking. Entire weeks of programming can be destroyed in a 15-minute phone call that (re)highlights a limitation clients either didn't account for in their specification (if you can call it that) or just chose to ignore. This isn't to say that using a language or framework a developer is familiar with is baseless, but I've heard this advice before and see it reinforced often: 1 - Hire people not skills. 2 - Success is 90% preparation.

astinit 10y ago

As someone still studying and not in the workforce yet, are there really teams out there that don't use version control?

Jackim 10y ago
Yes. I have a friend who does QA for a major university and that department doesn't use source control at all.
noir_lord 10y ago
Yes, I used to do a fair amount of consulting (aka nothing works properly, fix it, have this bag of cash) and I frequently ran into 'projects' that had no source control or had <projectname>/1 <projectname>/2 <projectname>/2a_1_fix_foobar :|. One of the things you'll learn if you hang around Hacker News/online programming communities is that a lot of the people in those communities are at the top end of the spectrum (there is a degree of self-selection that means a higher proportion I think). It's pockets of relative sanity in a sea of disaster.
hfsktr 10y ago
Yes, my first job we have 3-5 devs at some points. We each had our own codebase (internal site, external site, console/windows apps). We never touched each others' code. Nobody ever set up source control for the code I had to work on and nobody but me ever worked on it, the others did have source control as far as I know and at least one had 2 people working at a time. We did try to get my using it but it was clunky and didn't last long since it was just me using it. It seems so strange in hindsight but that whole place was so so different from where I am now.
the_af 10y ago
Yes. Also, some huge multinational companies you're very likely to have heard of don't do automated testing of any kind, as least for non-critical software (source: my own experience). I'm not talking about TDD or any fancy agile technique; I mean any kind of automated testing whatsoever. If you're just out of university or read tech blogs or hackernews, you'd think everyone these days is doing TDD, pair programming and agile. The reality is that a lot of major businesses do none of that.
- Pr3fix 10y ago
  Because in a lot of ways those practices don't further the end goal or bottom line of the business. They don't meet business needs. As a developer, I think we both can agree that these things make our (developer) lives easier, but they often don't help the bottom line of the company. I know some dev will retort this, but if I was wrong then companies would be mandating these practices top down.
  - mgkimsal 10y ago
    It's primarily perspective. I just came off a short term project which... yeah, it worked, but it's a disaster (but.. yeah, still working, technically). 4 years of no version control, no test environment for at least a year (it was shut down then never turned on again), no written docs, no written tests (and for periods of time, no backups). This software manages and controls 9 figures of USD annually. The 'bottom line' was/is always "i need a form that does X" and "I need a form/report to show Y". Yes, the immediate short term goals of the business worked. The entirety of the codebase has been hardcoded to work with library calls that were known tech-dead-ends years ago. The business now needs someone else to come in and manage things, because the original guy left. The business is now up a proverbial creek, because everything was in someone else's head. TDD/testing/docs externalizes some of that, and does have real business value, but it requires someone to be able to look more than 6 months in to the future with respect to tech decisions. Their bottom line will be hurt over the next year because they will be needing to pay far more to repair the tech debt, and it will mean fewer new things get done (or.. they'll pay even more for that). So... "business value" needs to be defined as to how you're measuring it, and 'short term' is always easier than 'long term'.
nine_k 10y ago
You have a chance to see all manners of known bad practices in the wild. It's important to recognize them as bad. It's also important to try to understand what lead to their adoption; often there are ways to work around that and apply a best practice in your area, even if other areas still suffer without it.
Roboprog 10y ago
Almost all teams these days that I know of have a revision / source / version control system of some kind purchased and installed. The "purchased" ones are usually worse than the open source ones (e.g. - Git, SVN et al). The "ENTERPRISE!!!" devs don't use the system effectively, usually: haul things off to a corner for weeks before doing a single check-in/commit; may or may not know how to branch; bumble with breakage during merge/pull operations; end-run the system by releasing non-compiled files directly to production without saving them in source control. Source control use is like the other comment about programming language: the main issue is not whether you have used brand X, but whether or not you have a coherent mental model of what the hell you are doing in the first place. That said, there are some BAD commercial source control systems out there, preying upon the "you need this, even/especially if you don't really know why" crowd. These are usually sold to The Management in terms of the control they bring to source control - they will have a trigger to force entry of a trouble/enhancement ticket to go with a check-in/commit. That fact that they suck at source management is of no consequence (e.g. - painfully slow, little to no command line interface for automation, poor research/discovery features, poor branch/merge support, unreliable / data corruption)

lordofmoria 10y ago

"Must know tech X" is exactly the mentality that we try to avoid in our company's hiring process. Most people would claim this makes your job descriptions too flexible, but the demand is actually incredibly specific: developers who can jump on a project in a tech they haven't "used" before and succeed 90% of the time. It's probably the case that only 10% of devs can do that comfortably though. Fits the criteria in 'Who' perfectly!

ekidd 10y ago

> Every project I've been brought in on, the qualifier was "must know tech X". And almost always (there were exceptions) I knew more about tech X and software dev in general than the original developers, and the crunch was not "how do I do XYZ in this tech?" it was "how do I get the other developers to actually use version control?" or "use version control sanely?" or "document anything?" or "write tests" or "have test data" or "have a repeatable build process"? I've seen this so many times on consulting gigs and with the occasional new employer. I'm hired because I'm familiar with the technologies they're trying to use, but the first major value I bring to the organization is simply getting some kind of sane process: working version control, automatic builds, test suites, one-button deploys, and so on.

mi100hael 10y ago
> I've seen this so many times on consulting gigs and with the occasional new employer. Same, and it's getting really fatiguing. Probably the #1 driver for me to get a side-project off the ground is to finally actually write code and not just play janitor for someone else's mess.

halisaurus 10y ago

> Stressing the "deliver quickly" aspect of any language, if you're actually trying to deliver for a business or with a team of people, is extremely destructive short term thinking. And yes, sometimes, in rare cases, it may be a necessary evil, but I think it's become the norm with words like "agile" being thrown around as synonyms for "don't have to write anything down". Unfortunately, this is pervasive in the "real world", especially with regard to client-driven (agency) work. Deadlines beat developers almost without fail. I agree that it is destructive short term thinking. Entire weeks of programming can be destroyed in a 15-minute phone call that (re)highlights a limitation clients either didn't account for in their specification (if you can call it that) or just chose to ignore. This isn't to say that using a language or framework a developer is familiar with is baseless, but I've heard this advice before and see it reinforced often: 1 - Hire people not skills. 2 - Success is 90% preparation.