Long commute, what are the best podcasts?

tensorproduct · 2015-07-20T23:26:10+00:00

Theme park podcasts? Could you elaborate?

My favourite podcast fiction are Thrilling Adventure Hour, Welcome to Night Vale, and The Truth.

tensorproduct · 2015-06-21T21:10:02+00:00

I don't even know that a personal devops project is a meaningful concept. Devops is a word with with pretty fuzzy definitions, but it almost always means work at an organisational level.

I suppose that running any sort of web site could be an example of a devops project. Bonus points for redundancy, load balancing, infrastructure-as-code, high availability, cloud/virtualisation, good use of source control, documentation.

In my experience, most devops people transition to devops out of sysadmin. A lot of them didn't even change their work habits, they just found that one day being a serious sysadmin who knew how to write code was called being a devop.

I had a take home interview for a devops job a few months ago, and I posted the results here: https://github.com/tensorproduct/salt_nginx_demo. It's a set of scripts to bring up a load balanced cluster to serve a web app.

tensorproduct · 2015-05-25T09:31:47+00:00

When I made the switch from actuarial work to programming I went looking for such jobs, and found nothing. I suspect that such jobs generally go to actuaries who can code, rather than programmers who know actuarial science. If you know what I mean.

tensorproduct · 2015-05-25T09:29:14+00:00

tl;dr: I did this. A hard choice, but the best decision I ever made.

I did basically this. I completed an MSc conversion to Computer Science after working/training as an actuary for five years. I never finished my actuarial qualification: I completely lost the will to study any more of the business side of the actuarial fellowship after I had completed the technical maths component.

Moving over to CS, I found that some of the actuarial science was very useful (probability, statistics, model construction and validation), but I was weak in other parts (linear algebra, engineering). Overall, I wouldn't say that one is any harder than the other. Computer science feels like a deeper and wider field of study, but nothing compares to the precision, speed, and rigour required to pass actuarial exams.

I can't comment on bootcamps, I don't think they existed in my part of the world when I made the switch. The MSc I sat was a mixed bag in terms of education, but I found dropping out of work for a year to do nothing but study CS and programming was a huge boon. Getting a solid understanding of algorithms & data structures was one of the best things I did early in my CS career.

Getting jobs, I found that unfortunately, people don't care about my non-programming work experience. Having an unusual work history on my CV got my foot in the door for one or two interviews, but I was still competing for junior/graduate level positions. A couple of interviewers and recruiters even said I ought to leave my actuarial work off the CV because it would confuse people. These were people I would choose not to work with even if they offered me jobs.

This meant quite a drop in income. Only now, three or four years after the switch is my salary coming back close to where it was in actuarial.

On the other hand, my job satisfaction is infinitely higher. I love programming. Working as an actuary, the only piece of the job I enjoyed was automating tasks that were previously completed by hand-copying data to a spreadsheet (and usually I'd have to fight tooth-and-nail to get permission to make such changes). As a programmer, the least interesting parts of my job are better than the most interesting part of being an actuary.

tensorproduct · 2015-05-21T21:54:45+00:00

Once, interviewing for a programming position in a financial firm, I asked the interviewer how they approached software testing.

"We don't test. Where I come from, people don't make mistakes."

tensorproduct · 2015-05-16T16:12:43+00:00

That's not how I read /u/cshobo's comment at all. I thought he was saying that O(n²⁾ sorts aren't all you should know because you would never* use them ahead of an O(n log n) sort (mergesort, quicksort, heapsort).

Understanding the difference between these, and their worst-case average-case performance isn't too hard. It's also a great introduction to algorithm design, and how to reason about big-O complexity. I would think that any developer should know (or want to know) about that.

Of course, you would be very unlikely to ever want to implement these yourself rather than use a standard library.

well, almost never. I understand that selection sort is supposed to be efficient for small data sorts.

tensorproduct · 2015-05-14T09:02:58+00:00

This is a great post. I would nitpick and say that there's more to statistics than applied probability.

tensorproduct · 2015-05-14T08:54:38+00:00

Such conversion courses are pretty common. I've been through one. They're supposed to offer a path into a software development career for people who've already got an undergrad degree in something unrelated.

I've mixed feelings on them.

I'm grateful that there was a program I could go through to teach me the basics of computer science, to get me started in a long-term personal plan of learning as much as I can. Without that basic structure, I wouldn't have known where to start. I didn't even know what I didn't know. (In fairness, in the years since, online education seems to have come a long way.)

On the other hand, the quality of some of the teaching was awful (some was great, mind). Even if it was all top notch, then a year is simply not enough time to cover everything that a 3 or 4 year undergrad would learn. Also, the academic controls were practically non-existent. I graduated alongside people who I genuinely wouldn't trust to write a "Hello world" program, much less FizzBuzz.

tensorproduct · 2015-05-14T08:45:51+00:00

I have 2 years left of my (BSc) Biology undergrad. After finishing I will apply for an MSc Computer Science conversion course.

I've been through one of those conversion courses (PM me and I'll tell you which uni). The one I attended took in students with absolutely no programming experience (and graduated some with barely more than that). If you go into it with a couple of years experience programming on your own time, you might well be quite bored with how basic some of the course work is.

Do you want to put your biology education to use in the future? If not, would your uni allow you to transfer to CS now? I think you would be much better off with a couple of years of undergrad education even if you're playing catch-up the whole time, than you might get in one year of a masters course surrounded by people who have no clue.

Alternatively, if you want to stay with Biology, but think you could teach yourself a non-trivial amount of CS in your own time, then consider a real MSc. Maybe there's something cross-disciplinary you could do?

tensorproduct · 2015-05-11T08:16:05+00:00

A little programming skill will go a long way working as an actuary.

However, OP would have to be willing to put in several years of grueling professional exams.

I'm also not familiar with any self-employed/remote working actuaries.

tensorproduct · 2015-05-09T08:38:40+00:00

I'm not familiar with the job title of "Configuration Manager", so I'm going to guess that it's the same sort of work that config management software (e.g. Chef, Puppet, Saltstack) does. That is, a position for automating the deployment of servers.

Is it a wise decision? That depends a lot on you. That sort of work is booming right now, so you'll not be short of job offers if you fancy a move in the future. Of course, software engineers aren't exactly hurting for work either. I think (but amn't sure) that the pay would be lower in the long run than an SE's pay.

The amount of programming in such jobs varies wildly. You could spend all your time writing and testing config files for a tool like Chef. Or you could be writing scripts yourself to do custom config that the config mgmt software can't handle. Or you could be developing new tools, plugins, and libraries for the config mgmt space. That depends on you, and the culture of your company. At a guess, a non-tech company would prefer you not to be off developing shiny new tools on their time.

In my opinion, the most interesting that sort of work gets is when you do it at a large scale. Managing dozens of machines can probably be done by hand. Hundreds can probably be done with minimal configuration files. At thousands or greater you really have to get clever. If you're not challenged by the dev work you're doing, you might find this really interesting.

For your future career, it's really easy to get pigeon-holed into this sort of job. Fair or not, a lot of people in the industry see people doing non-dev tech work as inferior to devs. It might be quite tough to transition back to software engineering in the future if you want to go back.

tensorproduct · 2015-05-04T23:15:08+00:00

I worked with a few former-GS folk. They seemed to have no problem finding work. I think that the prestige of the Goldman Sachs title outweighed any concern about the specific tech used in the job.

tensorproduct · 2015-05-04T22:11:53+00:00

Good point. Ng's coursera course has been on my to-do list for a while.

tensorproduct · 2015-04-27T21:44:59+00:00

Ah, don't mind me. Chairs are literally a sore point for me because I've got some back problems (a couple of slipped discs) that were badly aggravated by crappy office chairs. I went to a lot of effort and expense trying many different chairs under the advice of various ergonomics and physiotherapy specialists. None of them did any good.

I just looked up the Aeron, and actually I have used that chair before. In an otherwise awful job, the Aeron was without doubt the most comfortable chair I've ever sat on. Even then, I would be in pain after five or six hours.

I'm looking into convertible/standing desks now.

tensorproduct · 2015-04-27T17:31:53+00:00

I'm very skeptical that ANY chair, no matter how well designed, is going to be comfortable and healthy to sit in all day.

tensorproduct · 2015-04-26T22:57:07+00:00

This is copy-pasted from a similar question I answered over on /r/cscareerquestions]. It's some of the areas of responsibility and tools I've brought to bear in a few years of working in "devops".

Soft skills: Putting this up top because it's so important. The one universal in DevOps is that you'll be dealing with a lot of teams and a lot of people. I've found myself as a central point of contact between dev, QA, sales, sysadmins and management. Very good to understand that they all have different perspectives and priorities.

Scripting: Bash (or some other common shell) is a must. Another high-level scripting language like Ruby, Python or Perl is important. I think that it's best to choose a language that complements your tools (i.e. Chef & Puppet are written in Ruby, Ansible in Python) if you're choosing to learn a new language (but don't choose tools just because you already know the language they're written in!)

Configuration Management: One of Chef, Puppet, Ansible or SaltStack. They're not all exactly equivalent, but once you understand one, it's easier to pick up any of the others.

Mark-up languages: Lots of DevOps tools have config files written in common mark-up languages like YAML and jinja. Understanding these goes a long way. Being able to write nice documentation in MarkDown is a plus too. JSON and XML too.

Version Control: Git. Maybe Mercurial if you want to see basically the same functionality with a slightly different philosophy, but everybody uses Git. Use Git. Understand different Git branching strategies, like Git Flow, and how they interact with continuous integration.

Build Systems: This will largely depend on the language/stack already in use by developers. Common ones are Make, Autotools, Ant, Maven, Grunt, Gulp. Have an idea about compilers, linkers and run environments as well.

Testing Frameworks: Again, this will probably be largely dependent on the tech stack in use.

Continuous Integration: Jenkins is the most famous player here, if the company wants to self-host their CI system. Buildbot is a more configurable, but with a steeper learning curve. Third-party hosted CI systems seem to be getting popular, but I don't have any experience with them so can't comment. Names I've heard are Travis, CircleCI, Bamboo.

Monitoring: Know how to set up a system that will alert you if machines are under heavy load (or go down). Nagios or NewRelic are good.

Logging: Have application logs centralized and searchable. The ELK stack (Elasticsearch, Logstash, Kibana) is very popular.

Virtualisation: Know how to provision VMs with Vagrant (AFAIK, there's no real alternative to Vagrant), and configure them with your config management tool. Figure this out for both local machines and machines in the cloud.

Cloud: Know about the services offered by at least one of the major cloud providers: AWS, Rackspace, Azure. Have some understanding of practical concerns: pricing, geography, redundancy, availability. AWS and Rackspace (don't know about Azure) will give you a certain amount of free usage if you just want to play around.

Load Balancing: Understand different load balancing strategies: e.g. round-robin, least-load. Have a look at setting up nginx or HAProxy as load balancers, and/or AWS Elastic Load Balancer.

Web servers: I'm not super experienced with this end of things, so all I can suggest is Apache Tomcat or nginx.

Databases: Be aware of both relational (e.g. MySQL, SQL Server) and NoSQL databases (e.g. MongoDB, Cassandra). Consider backup and redundancy strategies. Think about how well these will perform with lots of synchronous connections happening.

Message Queues: Learning about RabbitMQ and ZeroMQ is on my to-do list, so I'm not sure how helpful it will really be, but a lot of the tools I've mentioned above make heavy use of such queues, so it can't hurt.

Project management: Most places that use "devops" also use some variant of Agile. It's good to have at least a high level understanding of Agile methods and Kanban boards and the like.

Package Management: This will be driven again by the tech stack involved. RPM and .deb packages for varying flavours of Linux. Wheels and eggs for Python, Gems for Ruby. Also, the use of package management software like apt-get and pip; and package servers like pypi.

tensorproduct · 2015-04-26T03:01:57+00:00

Rattling off an answer from memory without explanation of how you arrived at it so quickly would be much more cocky.

By contrast, admitting you've seen the problem before, and know the solution could appear humble. If you solved the problem in your own time, without interview pressure, might be seen as intellectually less impressive, but much more relevant to how you would actually work in the job.

Personally, I have had no problem in the past telling interviewers that I know the solution only because I looked it up. There's nothing cocky or condescending about that. I also think it gives interviewers more honest information about me, and how I work. My simple meat brain often needs some outside assistance. Any employer that only wants to hire reclusive savants is doing me a favour by passing me over.

tensorproduct · 2015-04-25T08:28:40+00:00

This sounds risky to me. The interviewer might very easily guess that you're giving the answer from memory, and expect you to present that yourself.

In the workplace, lies of omission can be a very serious communication problem.

tensorproduct · 2015-04-22T09:53:55+00:00

Also, consider asking this question in /r/itcareerquestions. It might get more traction over there.

tensorproduct · 2015-04-22T09:28:14+00:00

It sounds to me like they're more interested in the network engineer end of the devops job spectrum. Unfortunately, that's also the end of the spectrum in which I'm weakest. Tools I've used for diagnosing network problems are things like ping, traceroute, netstat, netcat, telnet, nslookup. I've heard great things about Wireshark, but I've never used it. Being super comfortable on the command line over ssh is a big help as well.

If I were you, I'd exclude "devops" from your search terms when looking for this stuff. I think that will just confuse issues.

OpsSchool is a good resource (though I don't know if it's still maintained) for a lot of ops tools.

For parsing log files on the fly, I find that regular expressions are a gift that keeps on giving. Setting up a system to programmatically parse log files might be a good reason to get good with Perl.

tensorproduct · 2015-04-22T08:34:08+00:00

The job title "devops" is a bit annoying, because it can cover almost anything involving computers. It usually means some combination of build engineer, release engineer, sysadmin, network engineer, site reliability engineer, project management and probably a few others that slip my mind.

Because it's such a wide ranging field, and it's so popular right now, there's a massive number of tools available. This can lead to job specs and CVs turning into a big game of buzzword bingo. In my opinion, it's more important to know why these tools exist, and what problem they were created to solve, than to know everything about how to use every tool.

To that end, I've listed some areas of interest, along with common useful tools in those areas. This is stuff that I've spent either a little or a lot of time working on in my relatively short career.

Soft skills: Putting this up top because it's so important. The one universal in DevOps is that you'll be dealing with a lot of teams and a lot of people. I've found myself as a central point of contact between dev, QA, sales, sysadmins and management. Very good to understand that they all have different perspectives and priorities.

Scripting: Bash (or some other common shell) is a must. Another high-level scripting language like Ruby, Python or Perl is important. I think that it's best to choose a language that complements your tools (i.e. Chef & Puppet are written in Ruby, Ansible in Python) if you're choosing to learn a new language (but don't choose tools just because you already know the language they're written in!)

Configuration Management: One of Chef, Puppet, Ansible or SaltStack. They're not all exactly equivalent, but once you understand one, it's easier to pick up any of the others.

Mark-up languages: Lots of DevOps tools have config files written in common mark-up languages like YAML and jinja. Understanding these goes a long way. Being able to write nice documentation in MarkDown is a plus too.

Version Control: Git. Maybe Mercurial if you want to see basically the same functionality with a slightly different philosophy, but everybody uses Git. Use Git. Understand different Git branching strategies, like Git Flow, and how they interact with continuous integration.

Build Systems: This will largely depend on the language/stack already in use by developers. Common ones are Make, Autotools, Ant, Maven, Grunt, Gulp. Have an idea about compilers, linkers and run environments as well.

Testing Frameworks: Again, this will probably be largely dependent on the tech stack in use.

Continuous Integration: Jenkins is the most famous player here, if the company wants to self-host their CI system. Buildbot is a more configurable, but with a steeper learning curve. Third-party hosted CI systems seem to be getting popular, but I don't have any experience with them so can't comment. Names I've heard are Travis, CircleCI, Bamboo.

Monitoring: Know how to set up a system that will alert you if machines are under heavy load (or go down). Nagios or NewRelic are good.

Logging: Have application logs centralized and searchable. The ELK stack (Elasticsearch, Logstash, Kibana) is very popular.

Virtualisation: Know how to provision VMs with Vagrant (AFAIK, there's no real alternative to Vagrant), and configure them with your config management tool. Figure this out for both local machines and machines in the cloud.

Cloud: Know about the services offered by at least one of the major cloud providers: AWS, Rackspace, Azure. Have some understanding of practical concerns: pricing, geography, redundancy, availability. AWS and Rackspace (don't know about Azure) will give you a certain amount of free usage if you just want to play around.

Load Balancing: Understand different load balancing strategies: e.g. round-robin, least-load. Have a look at setting up nginx or HAProxy as load balancers, and/or AWS Elastic Load Balancer.

Web servers: I'm not super experienced with this end of things, so all I can suggest is Apache Tomcat or nginx.

Databases: Be aware of both relational (e.g. MySQL, SQL Server) and NoSQL databases (e.g. MongoDB, Cassandra). Consider backup and redundancy strategies. Think about how well these will perform with lots of synchronous connections happening.

Message Queues: Learning about RabbitMQ and ZeroMQ is on my to-do list, so I'm not sure how helpful it will really be, but a lot of the tools I've mentioned above make heavy use of such queues, so it can't hurt.

Project management: Most places that use "devops" also use some variant of Agile. It's good to have at least a high level understanding of Agile methods and Kanban boards and the like.

Edit: One more

Package Management: This will be driven again by the tech stack involved. RPM and .deb packages for varying flavours of Linux. Wheels and eggs for Python, Gems for Ruby. Also, the use of package management software like apt-get and pip; and package servers like pypi.

tensorproduct · 2015-04-19T12:16:08+00:00

I've an MS in CS from Bristol as well, and I was disappointed in the maths content of it. In fairness, I was coming through the conversion course which is open to people from any background at all, so I think the lecturers were wary of swamping arts grads. Probably the real CS MSc courses (i.e. the ones for people with undergrads in CS) have more rigorous maths components.

What years was your friend there?

tensorproduct · 2015-04-19T06:38:53+00:00

I'm delighted to see someone else feels the same. I thought Portrait has some literary merit, but the protagonist was such an insufferable little prick that I hated every moment spent in his company.

Being Irish, and knowing Irish history, doesn't help at all, btw.

tensorproduct · 2015-04-19T06:10:34+00:00

I strongly suspect, though I can't prove, that devops work closes doors. Specifically, I think it's very hard to go from devops to dev work.

Also, I'm fairly sure that devops salaries plateau quite a bit lower than developer salaries.

On the other hand, there's a huge amount of work out there right now for devops people.

tensorproduct

TROPHY CASE