_d8fd
In Ruby, if I'm trying to find the source of a dynamically generated method in a dynamically generated class, that usually requires me to run add a debug statement, run the program, and see what's being passed. Even if I have a stacktrace, I often find it difficult to understand what the code is doing without running it.
I find Elixir code easier to read, and grepping my way through the code base is often enough. And to be fair, a debugger is often less than useful in macros involving AST & when dealing with a process that got a random message from who knows where.
You can think of insurance as a small & certain loss to hedge against a large & uncertain loss.
If stuff happens and you do need to cash in on that insurance policy, the payout should be thought of as saving your butt, also known as indemnification.
An airbag in your car is a form of insurance. You spent $X to protect yourself in a collision. The small & certain loss is spending the $X. Say you unexpectedly end up in a crash, but instead of dying, the airbag saves your life. It protected you from a death, the large & uncertain loss.
The idea of that buying an insurance is making a bet against yourself doesn't make sense to me. Insurance is more about making sure you don't lose. It's reducing risk, and a bet feels like taking on risk. The insurance company is the one making the bet, not the policy holder.
A friend of mine works at a large enterprise company on a multimillion dollar software project. Their dev team has never spoken to a customer or product manager (there is a PM team, they've just never spoken with the devs). It also takes them a long time to ship software. It's very odd.
Pros:
- easy enough to find libraries for most things I wanna do
- community likes testing, as do I
- community seems to focus on business & web implementations, so good for those use cases
- lots of questions for which I want answers already answered
- package management
- deployment to PaaS/Herorku-ish platforms pretty easy for smaller teams
- here in San Francisco, there are lots of job opportunities for Rails developers
- I like Ruby, even though I am less excited about OOP these days
Cons:
- Rails is magical & opinionated, and that always annoys me
- Figuring out where some method is coming from in a Rails object is often a pain
- In Elixir I almost never need a debugger, but in Ruby I almost always do
- loading Rails apps can get really slow, and learning to wait for software to boot isn't a skill I like to develop
- I feel more pressure "to do it" right when the time "to do it right" simply doesn't exist for reasons, because trying to come back and refactor gnarly Ruby code is just harder than it is in a compiled language
- Ruby has to be installed on the system to which an app is deployed, and needing to think about how to pre-install Ruby or how long a Ruby install takes is a mild pain (stand alone Go binaries or Elixir releases are pretty sweet)
- don't run out of cash
- make something you enjoy working on
- sell something people need
- sell something for more than it costs to make
- don't expect the people around you to be as excited as you are about your thing
My personal, non-software example was to identify an untapped opportunity in my field, technical recruiting. My clients had 20 to 100 employees, no internal technical recruiter, had already recruited their core team, has run out of organically generated people to interview, and had raised a Series B or later in funding. In 2010, the only options available to them were contingency recruiters, contract recruiters who wanted 6 to 12 month full time contracts, and inexperienced admin staff (aka not experienced technical recruiters).
After learning that it super competitive to sell traditional recruiting services to my clients, I decided to develop a workflow that allowed me to offer them part-time hourly recruiting with no long term commitment. Typically this started off as 10 to 30 hours a week with no commitment (aka fire me at any time). This model worked great, and in 2 years I scaled from just me billing 30 hours per week with one client to 15 people (part time & full time) billing several hundred hours per week.
Service business are not software businesses, but they do share at least one thing in common; selling a product or service customers need & can't buy in an industry you understand is a heck of a lot easier than trying to make something up from scratch.
Good luck!
</rant>
Another nice perk is working a banker you can call who understands the cash needs of startups. You can speak to a person in plain English about how your whacky business model needs to work. They see all sorts of new weird stuff, and they are conditioned to want to help you. The value of having someone understand the highs and lows of startup life, and who will go the extra mile to resolve any hiccups is subtle, but nice. Basically, a startup banker for startups is nice in the same way a farming banker is nice for farmers.
They can also help introduce you to investors. Having a banker on your side when you're raising capital is not trivial.
That is all that comes to mind.
>> In most cases when a company rejects you because of "culture fit", chances are there's something wrong with yourself.
I completely disagree. Interviewing teams reject candidates for all sorts of reasons that have nothing to do the candidate.
Reasons (valid or not) a applicant gets reject include:
- thinking candidate would get bored in a menial job
- discrimination
- unstated hiring freeze
- position is closed during hiring process
- position requirements are revised
- candidate wants to pair program, company does not, and vice versa
- interpersonal communication challenges, mostly around language barriers
- candidate seems too expensive
- candidate seems way too cheap, which seems too good to be true
- company believes candidate will not tolerate commute for extended period of time
- candidate bugged recruiter one too many times about status of interview process
- candidate overdressed for interview
- candidate underdressed for interview
- candidate reminds an interview too much of themself ("I'm the vision person, and we need some who likes to build the plan I come up with")
- the job is a demanding grind, and everyone who previously had kids has quit
- company doesn't like candidates education
- company worked for a stigmatized employer
- a backdoor reference check doesn't go well
This list could go one forever, and none of these things are something wrong with the candidate.
Source: was recruiter, saw people rejected for all sorts of reasons
"Would you like to go to @codeclub"
"Yes!"
"Ask HN: How should I teach code to kids?"
Getting kids an opportunity to become interested in @codeclub is a related, but separate question.
Are the kids remotely interested in programming, and does it make sense to try teaching them if they show no interest? As a child, I remember pushed towards taking piano lessons and hating every second of it.
If you need a dog crap collector, sell the job as a poop scooper, not a pre-compost collections technician.
I'd like to offer a spin on this.
In my experience, asking a question that demands one to recall specific details about a painful event in an interview, which is typically a stressful situation, may produce poor results.
What do you think about giving the candidate an opportunity to get advance notice of that you'll be asking that question, in an interview, and ask them to prepare three to five bullet points to discuss? Whether the candidate sends the bullet points back to you before the interview, or just brings them to the interview, is beyond the scope of what I'm proposing.
Let's say your trying to assess a 3 things:
* Has Architect been through the meat grinder at all? Bullet points with little depth log a warning, as there has been plenty of time to prepare a thoughtful answer.
* Does Architect talk about failure in a calm and composed manner? Bullet points give ability to ability to recall challenges before stress of interview sets in.
Does Architect trash talk former employer or coworkers? The stress of interview can erode one's asshole filter, and cause them to be a bit of the jerk they've worked really hard to not be (speaking a bit for myself here).
To wrap this up, I like interview questions that are functional with minimal side effects, meaning the person is given every opportunity to provide the answer you are looking without external pressure or distraction. If you want to see how a person handles stress, give them a situation that is stressful in a way it'd be on the job, perhaps leading with "apologies in advance for the following situation, which is intentionally stressful..."
About 10 years ago I decided to become a one person tax expert, read a NOLO press book on incorporating, and found what I thought was a clever solution to optimizing taxes in the most favorable manner. About a year later, my accountant told me two things... 1. "I've never actually seen a client choose this tax structure" 2. "You picked the worst possible taxation vehicle for your business, which is hard to do on purpose!"
My Google-fu thinks FOB is short for Forward Operating Base.