Here’s kind of an interesting question I’d have for this community.
You almost certainly do not need a degree
On almost every job posting that I’m a part of hiring for, we put that the candidate needs at least an associates degree, with a preference of bachelors. Not a degree in the field we’re hiring for (software dev), mind you, just a degree. In the past, I’ve found that if we don’t put that, we get a lot of applicants that are self-taught and have learned what they know through either online tutorials or coding bootcamps.
While I think you can learn a lot by teaching yourself or going through bootcamps, I have not found a single applicant that has done so that really learned how to think critically about software development. They come prepared by knowing all the answers to the book of “common software development interview questions” but never seem to be able to just think about a problem.
I’ve found that people who at least went through some kind of “college”-type education generally are better interviewees, regardless of whether it’s in our field.
Does anyone have that same experience? Or a way I can word a job posting that’s not “critical thinking required”? I know that’s a pretty big generalization to make, but as someone who ends up interviewing almost everyone that applies to a job (we don’t have some magic resume spit-out-if-you-don’t-have-20-years-experience-in-spacecraft-design tool), I have felt like without this on job postings, I struggle.
I have not found a single applicant that has done so that really learned how to think critically about software development. They come prepared by knowing all the answers to the book of “common software development interview questions” but never seem to be able to just think about a problem.
How does this manifest concretely? And does that mean they are incapable of producing software?
Either thinking about a problem is not needed to produce software (I don’t buy it), or degreeless people can’t produce software (obviously false). Maybe there are many bad apples. Or maybe these people just don’t interview well, which makes it look like they’re unable to think?
I’d be interested in seeing some examples of problems they are unable to think through.
I haven’t conducted interviews, but I know plenty of darn good programmers without degrees. And I know programmers who only got their degrees a decade into their successful career. The degreeless people on my team wrote their own operating system that’s been used in production for, I don’t know, around two decades now? Oh, I’m degreeless too.
I haven’t conducted interviews, but I know plenty of darn good programmers without degrees.
Same, and don’t get me wrong there are many people I work with that don’t have them and are great engineers. And I guess this goes more towards young professionals (less than 3 years experience) without degrees. But in general I find that people that come out of programming bootcamps especially (the majority of people that I see that don’t have any degree but still apply) don’t ever really know how their program works. If there was a performance issue in the code they wrote, for example, they wouldn’t know how to start getting down to the problem.
I guess it’s more of a criticism of programming bootcamps?
I guess it’s more of a criticism of programming bootcamps?
I was about to suggest it. Then you said it. So, I’m just going to corroborate it.
It can also be true for people with degrees, though, since one can often bullshit through academic courses more than real coding. If one has to filter, one of the better ways to do it with unknown candidates seems to be giving them an exercise to work on that:
(a) is similar to what they’ll do at your company
(b) pays something if they complete the exercise
(c) takes significant time to complete but not enough to wear down folks who are already busy (job, family, many interviews).
(d) isn’t actual work your company needs done so people know you aren’t farming off work to unpaid or barely paid applicants to save on programming time. Is mocked up or not strongly adding to your bottom line.
That’s a recipe I got from others on HN and Lobsters mainly who I can’t recall right now. It’s not mine. It looked like decent compromise, though, if you couldn’t get trustworthy references or prior work on someone.
I’ll also add that people with degrees might have to pay down loans on those degrees. They can cost more for that reason. A person that didn’t have degrees, but did build their skills, might be able to do the same thing for less. However, a lot of employers like the idea a person committed to something for 2-4 years and finished it despite the difficulties. That might build character but maybe they just coasted. I still don’t trust that metric. You might be able to use it, though, if it’s a school or group in school with a reputation for building talent with some track record of what they did there. So, there’s some up’s and down’s to they have a degree.
Even though I fully understand the possible struggle, I still think that your “lazy” (allow me being lazy too for not finding a more appropriate word) attitude is bad and outdated.
I want to live in a world where if you break your back and study on your own but, for some reason, don’t have a degree, you still have a chance to land a junior job somewhere.
I want to believe that if a 30/40yo person who couldn’t afford going to university and decided to get a job as a programmer would only require to study 1/2 years by themselves, while doing their current job, and have hope to put even just a toe in the world of IT.
I want a motivated and somewhat talented youngster to be able to apply to their first real job right after school, before deciding on. whether focus their next 3/4 years on a more focused education at a university of their choice with their own money.
These are not abstract characters, these are actual people who are damaged by the “it’s easier this way” attitude. The person I would like to pass through the door is someone I can give a task (more or less demanding) and have them put their very best and succeed. Whether they went through the classic route or not should be completely irrelevant.
Sorry, maybe I’m a bit too optimistic or maybe I know far too many people with high-grades from university who I wouldn’t even trust with writing some documentation.
I can totally understand why you’d require a degree based on what you’ve said and seen.
Something I said later on in there though:
Tell people what you want, give them goals, and let them tell you how they satisfy them
At the moment, my understanding is that you’re requiring a degree partly as a way of demonstrating critical thinking ability
My gut reaction would be to strip out the degree requirement and replace it with a short test at application time (bearing in mind the caveats I mention around take-homes!) designed to test their ability to “just think about a problem”
This won’t be easy, and sure, it wouldn’t surprise me to hear that a lot of people who come through it successfully have degrees, but you’re still improving the accuracy of your filtering (by trying to practically test for the property instead of just testing for something that hopefully correlates) and you’ve opened it up to people who don’t
A few off-the-cuff ideas for tests that might help (I’ve not thought about these enough to claim they’re good though!):
“Here’s some code, write some documentation/warnings to users”
“Find the bugs in this code”
“What security concerns does this code raise”
Those are all things where you can have some easy obvious answers, but also deeper issues that should assess their ability to think about the bigger picture / further consequences of things, which feels like it should tie in with the “critical thinking” you’re after
we don’t have some magic resume spit-out-if-you-don’t-have-20-years-experience-in-spacecraft-design tool
Can you use your human eyes on the resume to get an even better result than such a tool would be? I’ve found that by looking up the website, projects, or Github profile on a resume I can weed out the bulk of the not-worth-interviewing enough to at least make the process not terrible.
OTOH, I’ve definitely interviewed (and even worked with) people who had degrees and couldn’t accomplish any useful task on the job.
This came up again in the context of the recent Dyn DDoS and comes up regularly in discussion of the Internet of Things and its general total lack of software or security.
Link? I’m wondering why people think this. Do you mean people are arguing it would have made taking over the IoT devices impossible in the first place, or that a static type system would somehow make handling a DDoS possible? In any case, I think any reasonable person would see through these statements pretty quickly. You can find someone who has said just about anything.
As static typing becomes more elaborate the scope of the bugs it can prevent becomes wider, but it comes with an additional cost: Build times.
Ocaml has pretty reasonable build times. IMO, I would say Ocaml build times are close to Go given how much moe expressive the type system is than Go’s.
My general experience of the correctness software written in fancy statically typed languages is not overwhelmingly positive compared to that of software written in dynamic languages. If anything it trends slightly negative. This suggests that for the scale of many projects the costs and benefits are close enough that this actually matters.
Having written and inherited code in a dynamically typed language, I can say the big win, in my experience, is refactoring. IME, a lot of people (on both sides) talk about producing code the first time. IME, that is pretty easy no matter what language one is it. Coming back to code 6 months or 6 years later is a much different story.
Coming back to code 6 months or 6 years later is a much different story.
Oh gosh this so much.
I’ve inherited various chunks of under-documented under-tested code over time. Type-y assistance where present has made all the difference in these situations!
Maintaining nearly 80KLOC of OCaml over three years, I was able to use repeated edit-compile-error-scratch-head sessions as a means to re-acquaint myself with the system. But this is such a low bar; we need better. Maintaining more than 1MLOC of Smalltalk over the past twelve years, I found leaning on a type system–even OCaml’s–to be quite impoverished compared to a live, self-navigating system of uniform, recursively designed objects and messages.
I’ve heard that refactoring smalltalk is a great experience. I don’t hear the same about erlang. Is this just a matter of the smalltalk folks focusing more on tooling? They’re such similar languages in a lot of ways, I would think you could achieve similar things, but I don’t hear people talking about refactoring erlang systems with such reverence.
I can’t do it justice in a few lines, and I don’t want to clutter the discussion here. I will say that’s not just about Smalltalk but the mindset that Smalltalk fostered and, in turn, fed back into the evolution of Smalltalk. Go back, at least, to the writings of Ward Cunningham, Kent Beck, Ralph Johnson, and Brian Foote. As for Smalltalk itself, tooling almost emerges spontaneously from it because–I think–of the attributes I noted in the last line of my previous reply.
to be quite impoverished compared to a live, self-navigating system of uniform, recursively designed objects and messages.
Do you mean that the code bases are uniform in this way or that any program written in Smalltalk will have this quality? One reason I like a good type system is because most code is not uniform and the type system let’s me take messes and make them clean, pretty safely. But a type system is no panacea, of course.
You can write bad code in Smalltalk, as in any other language. One thing that sets Smalltalk apart is that it’s as much a system as it is a language. Further, it’s a system represented solely in terms of objects sending messages to other objects. Further still, it’s a running, fully reflective, live system with that entire object graph readily introspected and manipulated. So, in Smalltalk–as Alan Kay said–architecture (uniform recursive object system) dominates materials (code). In Smalltalk, even bad code is easily navigated, understood, and refactored.
“Ocaml build times are close to Go given how much moe expressive the type system is than Go’s.”
Build time is measured the same, no matter the language. One could say a longer build time is justified because of certain benefits, but it’s still a longer build time.
I’m not sure what I said you’re disagreeing or correcting me on. I am saying Ocaml builds fast, but slower than Go, but you get a lot of typing out of that extra time.
Ocaml has pretty reasonable build times. IMO, I would say Ocaml build times are close to Go given how much moe expressive the type system is than Go’s.
It’s great to see a job posting on here. I’ve been trying to figure out how to find jobs without going through a recruiter for a while but I’ve more or less come up with nothing, so seeing this gives me a spark of hope.
For this job specifically I’m sort of tempted to apply since I’m familiar with everything you mention, and I want to continue my current pattern of working remotely, but I’m put off a bit by the title ‘Infrastructure Engineer’. I don’t think you can effectively work on infrastructure without a good understanding of the application(s) using it, and vice versa, so for my whole career I’ve been involved in both, and my job titles have been correspondingly general. Perhaps you could expand a little on that…?
Definitely. Looking at history though, it seems the tag has not been used correctly for the most part. I guess we need to be more vigilant about flagging those that are tagged job but aren’t job postings?
I guess we need to be more vigilant about flagging those that are tagged job but aren’t job postings?
Agreed! I’ve gone through and suggested removing the job tag from a few of the recent ones that are not actually job ads. If more do the same, I suppose they’ll be removed? It should help people who look at “prior art” to pick the right tag.
I’ve gone through and suggested removing the job tag from a few of the recent ones that are not actually job ads. If more do the same, I suppose they’ll be removed?
Just did the same, most of the recent job stories are now properly tagged. We did it! :)
I don’t think you can effectively work on infrastructure without a good
understanding of the application(s) using it, and vice versa, so for my
whole career I’ve been involved in both,
I absolutely agree. And there’s a good deal of overlap here. We are a company
of about 30 people. Because we’re so small,
we don’t have room for hyper-specialists. We don’t have a group of people who
develop the software, and another group that operates the software. We
have a degree of freedom and responsibility to do what we feel is right
for the company to succeed.
As an example I recently needed to do some maintenance on a small service
called from our main app. I first spent time investigating what would
happen to our main app in this case, by reading the code and looking at New
Relic during running the maintenance operation in our test environment. I
found that our main app was meant to handle this case, but due to a bug
it did not do so properly. I identified & implemented a fix, and waited
until the next release of the app to do the maintenance on the auxiliary
app.
and my job titles have been correspondingly general.
Personally (and I don’t speak for my boss who wrote the ad I linked to here) I think a job title is just a hook to hang the job description off
of. I don’t think one is terribly meaningful without the other, and I wouldn’t
worry too much about that label. For most of my career I too have been
involved in both development, deployment and live support of applications, although my job titles have been all over the place.
I’m not sure Russia deserves to be on this list any more so than the United States, Mexico and Canada, which are all somehow absent. Sure, some remote regions in Russia did end up being held hostage due to the politics and the timezone cleanup from Moscow, but as far as Moscow Time is concerned (which affects most of the population of Russia), changes have been announced at least several months in advance, and, thankfully, now with the elimination of the yearly DST changes all together since 2011 (and across all of Russia), things should be rather calm and quiet, although, to be fair, the original lack of much thought of whether there is any difference between the permanent winter time or the permanent summer time could probably have been given more thought, indeed.
I think what we really need in the world is the elimination of this stupid DST in the first place. Then instead of having to switch the clocks twice a year throughout most of the West (sans Russia, Belarus, Arizona, Hawaii, Saskatchewan), and experience the associated seasonal loss of productivity for a few weeks as a result, clocks could be set to a permanent offset from the GMT, and we basically wouldn’t so much as need any TZ files to start with.
This argument doesn’t hold up. Just move the whole timezone forward one hour and abolish DST, you’ll still have all the advantages of DST in summer while in winter (most) people will go to work and back home in the dark anyway.
That’s actually what Russia did in 2011 – abolished the winter/summer time, and went into a permanent DST in March 2011. Then come November, people supposedly started hated going to school/work in complete darkness in most of Russia, only to be greeted with the same darkness when coming back home. Of course, the opposition and the foreign-sponsored media blamed everything on the ruling party. So, in October 2014, Russia once again changed all clocks in line with the DST in Europe, only now going into a permanent winter time. Pretty neat!
BTW, reading http://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States, quite a few states did actually want to go into a permanent DST, but, apparently, the U.S. federal law, Uniform Time Act, prohibits states from extending daylight savings time, although I’m not exactly sure why they can’t just move into a neighbouring timezone on the winter time (which supposedly requires only a DoT authorisation, if even that), instead of remaining on their original timezone yet with a permanent DST.
For example, Nevada is now asking U.S. Congress to let it stay on permanent DST within its Pacific Time, which will result in Nevada having the exact same time as Arizona, only in Arizona the time is called Mountain Time (without DST). Why not just switch into Mountain Time, and abandon DST, just like Arizona did without needing any U.S. Congress approvals? After all, “Pacific” isn’t exactly what comes to mind when you’re thinking Nevada, now is it?
It’s not at all about just the technological simplicity – there have been studies that have shown that the incidence of health and safety related incidents increases dramatically around the time that the clocks shift (heart attacks, doctor visits, auto accidents). So, the “human aspects” by far exceed the technological ones.
Of course, the real-estate brokers, as well as the golf and the brick-and-mortar retail industry, will always campaign against the abolishment of DST. I am not at all surprised that your article in defence of DST was authored by a real-estate broker in LA.
Here’s kind of an interesting question I’d have for this community.
On almost every job posting that I’m a part of hiring for, we put that the candidate needs at least an associates degree, with a preference of bachelors. Not a degree in the field we’re hiring for (software dev), mind you, just a degree. In the past, I’ve found that if we don’t put that, we get a lot of applicants that are self-taught and have learned what they know through either online tutorials or coding bootcamps.
While I think you can learn a lot by teaching yourself or going through bootcamps, I have not found a single applicant that has done so that really learned how to think critically about software development. They come prepared by knowing all the answers to the book of “common software development interview questions” but never seem to be able to just think about a problem.
I’ve found that people who at least went through some kind of “college”-type education generally are better interviewees, regardless of whether it’s in our field.
Does anyone have that same experience? Or a way I can word a job posting that’s not “critical thinking required”? I know that’s a pretty big generalization to make, but as someone who ends up interviewing almost everyone that applies to a job (we don’t have some magic resume spit-out-if-you-don’t-have-20-years-experience-in-spacecraft-design tool), I have felt like without this on job postings, I struggle.
How does this manifest concretely? And does that mean they are incapable of producing software?
Either thinking about a problem is not needed to produce software (I don’t buy it), or degreeless people can’t produce software (obviously false). Maybe there are many bad apples. Or maybe these people just don’t interview well, which makes it look like they’re unable to think?
I’d be interested in seeing some examples of problems they are unable to think through.
I haven’t conducted interviews, but I know plenty of darn good programmers without degrees. And I know programmers who only got their degrees a decade into their successful career. The degreeless people on my team wrote their own operating system that’s been used in production for, I don’t know, around two decades now? Oh, I’m degreeless too.
Same, and don’t get me wrong there are many people I work with that don’t have them and are great engineers. And I guess this goes more towards young professionals (less than 3 years experience) without degrees. But in general I find that people that come out of programming bootcamps especially (the majority of people that I see that don’t have any degree but still apply) don’t ever really know how their program works. If there was a performance issue in the code they wrote, for example, they wouldn’t know how to start getting down to the problem.
I guess it’s more of a criticism of programming bootcamps?
I was about to suggest it. Then you said it. So, I’m just going to corroborate it.
It can also be true for people with degrees, though, since one can often bullshit through academic courses more than real coding. If one has to filter, one of the better ways to do it with unknown candidates seems to be giving them an exercise to work on that:
(a) is similar to what they’ll do at your company
(b) pays something if they complete the exercise
(c) takes significant time to complete but not enough to wear down folks who are already busy (job, family, many interviews).
(d) isn’t actual work your company needs done so people know you aren’t farming off work to unpaid or barely paid applicants to save on programming time. Is mocked up or not strongly adding to your bottom line.
That’s a recipe I got from others on HN and Lobsters mainly who I can’t recall right now. It’s not mine. It looked like decent compromise, though, if you couldn’t get trustworthy references or prior work on someone.
I’ll also add that people with degrees might have to pay down loans on those degrees. They can cost more for that reason. A person that didn’t have degrees, but did build their skills, might be able to do the same thing for less. However, a lot of employers like the idea a person committed to something for 2-4 years and finished it despite the difficulties. That might build character but maybe they just coasted. I still don’t trust that metric. You might be able to use it, though, if it’s a school or group in school with a reputation for building talent with some track record of what they did there. So, there’s some up’s and down’s to they have a degree.
Your comment made me a bit sad.
Even though I fully understand the possible struggle, I still think that your “lazy” (allow me being lazy too for not finding a more appropriate word) attitude is bad and outdated.
I want to live in a world where if you break your back and study on your own but, for some reason, don’t have a degree, you still have a chance to land a junior job somewhere.
I want to believe that if a 30/40yo person who couldn’t afford going to university and decided to get a job as a programmer would only require to study 1/2 years by themselves, while doing their current job, and have hope to put even just a toe in the world of IT.
I want a motivated and somewhat talented youngster to be able to apply to their first real job right after school, before deciding on. whether focus their next 3/4 years on a more focused education at a university of their choice with their own money.
These are not abstract characters, these are actual people who are damaged by the “it’s easier this way” attitude. The person I would like to pass through the door is someone I can give a task (more or less demanding) and have them put their very best and succeed. Whether they went through the classic route or not should be completely irrelevant.
Sorry, maybe I’m a bit too optimistic or maybe I know far too many people with high-grades from university who I wouldn’t even trust with writing some documentation.
I’d like to hear your opinion on this.
I can totally understand why you’d require a degree based on what you’ve said and seen.
Something I said later on in there though:
At the moment, my understanding is that you’re requiring a degree partly as a way of demonstrating critical thinking ability
My gut reaction would be to strip out the degree requirement and replace it with a short test at application time (bearing in mind the caveats I mention around take-homes!) designed to test their ability to “just think about a problem”
This won’t be easy, and sure, it wouldn’t surprise me to hear that a lot of people who come through it successfully have degrees, but you’re still improving the accuracy of your filtering (by trying to practically test for the property instead of just testing for something that hopefully correlates) and you’ve opened it up to people who don’t
A few off-the-cuff ideas for tests that might help (I’ve not thought about these enough to claim they’re good though!):
Those are all things where you can have some easy obvious answers, but also deeper issues that should assess their ability to think about the bigger picture / further consequences of things, which feels like it should tie in with the “critical thinking” you’re after
How’s that sound?
recommend they read “How to solve it” by George Pólya as part of the interview preparation?
Can you use your human eyes on the resume to get an even better result than such a tool would be? I’ve found that by looking up the website, projects, or Github profile on a resume I can weed out the bulk of the not-worth-interviewing enough to at least make the process not terrible.
OTOH, I’ve definitely interviewed (and even worked with) people who had degrees and couldn’t accomplish any useful task on the job.
If you weed them out, how do you know they were not worth interviewing?
What if your lookup turns up nothing?
That’s fair, my wording was perhaps suboptimal. I suppose I meant really that the bulk of those remaining are worth interviewing, which is the goal.
Link? I’m wondering why people think this. Do you mean people are arguing it would have made taking over the IoT devices impossible in the first place, or that a static type system would somehow make handling a DDoS possible? In any case, I think any reasonable person would see through these statements pretty quickly. You can find someone who has said just about anything.
Ocaml has pretty reasonable build times. IMO, I would say Ocaml build times are close to Go given how much moe expressive the type system is than Go’s.
Having written and inherited code in a dynamically typed language, I can say the big win, in my experience, is refactoring. IME, a lot of people (on both sides) talk about producing code the first time. IME, that is pretty easy no matter what language one is it. Coming back to code 6 months or 6 years later is a much different story.
Oh gosh this so much.
I’ve inherited various chunks of under-documented under-tested code over time. Type-y assistance where present has made all the difference in these situations!
Maintaining nearly 80KLOC of OCaml over three years, I was able to use repeated edit-compile-error-scratch-head sessions as a means to re-acquaint myself with the system. But this is such a low bar; we need better. Maintaining more than 1MLOC of Smalltalk over the past twelve years, I found leaning on a type system–even OCaml’s–to be quite impoverished compared to a live, self-navigating system of uniform, recursively designed objects and messages.
I’ve heard that refactoring smalltalk is a great experience. I don’t hear the same about erlang. Is this just a matter of the smalltalk folks focusing more on tooling? They’re such similar languages in a lot of ways, I would think you could achieve similar things, but I don’t hear people talking about refactoring erlang systems with such reverence.
I can’t do it justice in a few lines, and I don’t want to clutter the discussion here. I will say that’s not just about Smalltalk but the mindset that Smalltalk fostered and, in turn, fed back into the evolution of Smalltalk. Go back, at least, to the writings of Ward Cunningham, Kent Beck, Ralph Johnson, and Brian Foote. As for Smalltalk itself, tooling almost emerges spontaneously from it because–I think–of the attributes I noted in the last line of my previous reply.
Do you mean that the code bases are uniform in this way or that any program written in Smalltalk will have this quality? One reason I like a good type system is because most code is not uniform and the type system let’s me take messes and make them clean, pretty safely. But a type system is no panacea, of course.
You can write bad code in Smalltalk, as in any other language. One thing that sets Smalltalk apart is that it’s as much a system as it is a language. Further, it’s a system represented solely in terms of objects sending messages to other objects. Further still, it’s a running, fully reflective, live system with that entire object graph readily introspected and manipulated. So, in Smalltalk–as Alan Kay said–architecture (uniform recursive object system) dominates materials (code). In Smalltalk, even bad code is easily navigated, understood, and refactored.
“Ocaml build times are close to Go given how much moe expressive the type system is than Go’s.”
Build time is measured the same, no matter the language. One could say a longer build time is justified because of certain benefits, but it’s still a longer build time.
I’m not sure what I said you’re disagreeing or correcting me on. I am saying Ocaml builds fast, but slower than Go, but you get a lot of typing out of that extra time.
That seems reasonable. The original statement might be more clear to me if it said “close enough to Go given…”
That’s a good example, thanks. I’ll add it in.
It’s great to see a job posting on here. I’ve been trying to figure out how to find jobs without going through a recruiter for a while but I’ve more or less come up with nothing, so seeing this gives me a spark of hope.
For this job specifically I’m sort of tempted to apply since I’m familiar with everything you mention, and I want to continue my current pattern of working remotely, but I’m put off a bit by the title ‘Infrastructure Engineer’. I don’t think you can effectively work on infrastructure without a good understanding of the application(s) using it, and vice versa, so for my whole career I’ve been involved in both, and my job titles have been correspondingly general. Perhaps you could expand a little on that…?
TL;DR: Naming is hard - you should apply!
It’s the end of the day here, but I’ll get back to this tomorrow with an expanded answer.
Seconding this, it’d be nice to see more job postings on here. The tag can be filtered depending on if you’re in the market.
Definitely. Looking at history though, it seems the tag has not been used correctly for the most part. I guess we need to be more vigilant about flagging those that are tagged job but aren’t job postings?
Agreed! I’ve gone through and suggested removing the
jobtag from a few of the recent ones that are not actually job ads. If more do the same, I suppose they’ll be removed? It should help people who look at “prior art” to pick the right tag.Just did the same, most of the recent
jobstories are now properly tagged. We did it! :)I absolutely agree. And there’s a good deal of overlap here. We are a company of about 30 people. Because we’re so small, we don’t have room for hyper-specialists. We don’t have a group of people who develop the software, and another group that operates the software. We have a degree of freedom and responsibility to do what we feel is right for the company to succeed.
As an example I recently needed to do some maintenance on a small service called from our main app. I first spent time investigating what would happen to our main app in this case, by reading the code and looking at New Relic during running the maintenance operation in our test environment. I found that our main app was meant to handle this case, but due to a bug it did not do so properly. I identified & implemented a fix, and waited until the next release of the app to do the maintenance on the auxiliary app.
Personally (and I don’t speak for my boss who wrote the ad I linked to here) I think a job title is just a hook to hang the job description off of. I don’t think one is terribly meaningful without the other, and I wouldn’t worry too much about that label. For most of my career I too have been involved in both development, deployment and live support of applications, although my job titles have been all over the place.
I agree though!
Oh hai! ;-)
I’m not sure Russia deserves to be on this list any more so than the United States, Mexico and Canada, which are all somehow absent. Sure, some remote regions in Russia did end up being held hostage due to the politics and the timezone cleanup from Moscow, but as far as Moscow Time is concerned (which affects most of the population of Russia), changes have been announced at least several months in advance, and, thankfully, now with the elimination of the yearly DST changes all together since 2011 (and across all of Russia), things should be rather calm and quiet, although, to be fair, the original lack of much thought of whether there is any difference between the permanent winter time or the permanent summer time could probably have been given more thought, indeed.
I think what we really need in the world is the elimination of this stupid DST in the first place. Then instead of having to switch the clocks twice a year throughout most of the West (sans Russia, Belarus, Arizona, Hawaii, Saskatchewan), and experience the associated seasonal loss of productivity for a few weeks as a result, clocks could be set to a permanent offset from the GMT, and we basically wouldn’t so much as need any TZ files to start with.
I think it’s very easy to forget the human aspects in favour of technical simplicity: http://www.americanthinker.com/blog/2013/03/in_defense_of_daylight_savings_time.html
That feels very Anglocentric of you - given the ambiguities of “GMT”, UTC would seem a much better choice! ;)
This argument doesn’t hold up. Just move the whole timezone forward one hour and abolish DST, you’ll still have all the advantages of DST in summer while in winter (most) people will go to work and back home in the dark anyway.
That’s actually what Russia did in 2011 – abolished the winter/summer time, and went into a permanent DST in March 2011. Then come November, people supposedly started hated going to school/work in complete darkness in most of Russia, only to be greeted with the same darkness when coming back home. Of course, the opposition and the foreign-sponsored media blamed everything on the ruling party. So, in October 2014, Russia once again changed all clocks in line with the DST in Europe, only now going into a permanent winter time. Pretty neat!
BTW, reading http://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States, quite a few states did actually want to go into a permanent DST, but, apparently, the U.S. federal law, Uniform Time Act, prohibits states from extending daylight savings time, although I’m not exactly sure why they can’t just move into a neighbouring timezone on the winter time (which supposedly requires only a DoT authorisation, if even that), instead of remaining on their original timezone yet with a permanent DST.
For example, Nevada is now asking U.S. Congress to let it stay on permanent DST within its Pacific Time, which will result in Nevada having the exact same time as Arizona, only in Arizona the time is called Mountain Time (without DST). Why not just switch into Mountain Time, and abandon DST, just like Arizona did without needing any U.S. Congress approvals? After all, “Pacific” isn’t exactly what comes to mind when you’re thinking Nevada, now is it?
It’s not at all about just the technological simplicity – there have been studies that have shown that the incidence of health and safety related incidents increases dramatically around the time that the clocks shift (heart attacks, doctor visits, auto accidents). So, the “human aspects” by far exceed the technological ones.
Of course, the real-estate brokers, as well as the golf and the brick-and-mortar retail industry, will always campaign against the abolishment of DST. I am not at all surprised that your article in defence of DST was authored by a real-estate broker in LA.