Skip to content

HN Job Posting Thread

Person refusing bag of moneyIf you aren’t an avid follower of Hacker News, you might not be aware that once a month there’s a job posting thread on the site. This community has its rough edges, like any other, but this thread offers a great place to reach the audience–software developers, startup aficionados and technologists of all stripes. Here’s the April 2018 job thread.

I find this a bit more credible than the job sites because there’s community policing and because it expires there’s less incentive for recruiters or other bad actors gaming the system. Because it is free and specifies only employees of a company may post, I think that the job openings are more genuine. You often see hiring managers post their contact info, and an email to them is far more likely to get a response than submitting to an applicant tracking system. You can often find salary ranges, and the audience and posts are global. It’s also worth noting that this feeds into some other sites like whoishiring.io.

I have posted on behalf of a few companies for which I worked and have had a decent hit rate. Haven’t seen any real success numbers though.

Whether you are on the market, hiring, or just curious, more data is usually useful, which is why this is always a thread I peruse. If you want to look at previous months postings, you can see them in this bot’s submissions.

Jobs Recruiting | moore |

“Finding your purpose and living a meaningful life”

BatsA friend recently shared a letter from Hunter S. Thompson on finding your purpose. I found it to be quite insightful, especially on how he emphasizes a person should focus on “choos[ing] a path which will let his ABILITIES function at maximum efficiency toward the gratification of his DESIRES.” Choosing a goal is less important than choosing a way of life. I remember when I was chatting with my father about how he chose his career, he stated that in a world of choice you should choose some invariants and evaluate options based on those invariants. They don’t have to be job invariants, though sometimes they are. But if you don’t have a set of fixed standards, you run the risk of chasing after shiny objects again and again, or, worse, contorting yourself to some goal that previous you had settled upon. After some thought during this transition, these are mine:

  • Technology is the most fun and best when it helps people. I remember the joy of this in my first professional software project (mail merging insurance renewal letters). Watching people helped by software I built has been the highlights of my career.
  • No one every wishes they’d worked more on their deathbed. Work to live, don’t live to work.

It’s scary for me to lay out constraints because that means that you are ruling out possibilities. For instance, if a high flying Silicon Valley startup ever read this, they’d probably pass on my application due to my desire to not work 80+ hour weeks for the chance at winning the lottery. But that’s precisely the point. If the opportunity doesn’t meet my invariants, no matter how nice the paycheck or good the perks, it’s not a place that I’ll thrive.

PS Hunter S. Thompson also warns that every person’s advice is drawn from their experience and should be treated as subjecting–as Miles Law states: “where you stand depends a whole lot on where you sit“. Or to use Internet-ese: YMMV.

Lifehack | moore | | Leave a comment

Leaving well

Bird leaving eggLeaving a company in a way that is fair to both you and your company can be difficult. When employed, we spend a large portion of our waking hours at work. You may be leaving a group of people you loved, a toxic environment, a place you’ve outgrown, or a place you’ve loved and just need to move on from for personal reasons. Because of the amount of time invested and the multiplicity of emotional circumstances, it can be difficult to leave well. Below are some thoughts on this career transition, however, I’m not writing about why you should leave, just how the process should go once you’ve made that decision. (Note that some of these apply to transitioning positions within a company.)

Before you are thinking about leaving

  1. Prepare to leave well before you think about leaving by documenting your decisions, processes and systems. This has the added benefit of letting you do better in your current position. When you write down how you do a task, it gives you the chance to review it and consider optimizations, as well as revisit it in the future and perform the task just as well. Make sure to date all documents. When you revisit a system or process, revisit the document.
  2. Watch how other departing employees are treated. Expect to be treated in a similar manner. Some companies want to usher folks out quickly (to the point of just paying their standard two weeks notice immediately and having them depart) while others will be more flexible. Some managers will treat departing employees with compassion and respect. Others may not.
  3. You won’t be able to effect change at the company once you have publicly decided to depart. If you want to effect change, stay at the company work within the system.

Once you’ve decided to leave

  1. Save and put that money into a liquid savings account. How much? As much as you can. This will make the transition less scary and allow you greater flexibility.
  2. Decide on boundaries and stick to them. Being helpful with the transition doesn’t mean you have to be a doormat.
  3. It’s always easier to find a job when you have a job. Think about reactivating old networks, inviting folks for coffee, and checking out the job market while you are still in your position.
  4. When you decide to leave, give as much notice as possible. Since you’ve been observing how folks are treated and you know your own situation, adjust for those factors. However, I’ve found letting managers know about my departure with plenty of notice ensures a smooth departure. Personally, I’ve given up to two months of notice.
  5. I’ve never had a counteroffer, but I’ve read that accepting them is a poor choice.
  6. Make a plan with your manager. Take point on this, as you are the person who knows your job best. This plan should be your first task after you’ve told your manager you are departing.
  7. Keep a spreadsheet of departure tasks including owner, date to be completed and description. Sometimes important things are overlooked. This is where having documentation (see step 1) is helpful, but also look at your to-do lists, your and calendar entries.

Telling your fellow employees

  1. Let the company control the narrative about when you are leaving, including when to tell the team. However, if you are approaching your departure date and no one on the team knows, push your manager to publicize it.
  2. You will likely have many reasons for your departure. Pick a major, true, banal reason or two and answer with that when team members ask why you are leaving. There’s no need to get into every grievance, reason or issue you had.
  3. Your decisions will have less weight once you announce your departure. This is natural; team members that are staying discount your opinions because you won’t be living with the consequences. Prepare yourself for this.
  4. Consider offering to consulting to the company if it makes sense for you and the timing is right. Charge a fair market rate. Realize that stepping into this role may be difficult emotionally.
  5. Once your exit is public, your focus should be bringing other employees up to speed so they can do your job when you’re gone. It may feel good to bang out one more bugfix or initiative and if you have time to do that, great, but your primary focus should be on documentation and knowledge transfer.
  6. Realize that this transition will feel momentous to you, but that it is far less important to everybody else (both inside and outside the company). A company should have no irreplaceable employees.
  7. Treat everyone as fairly as possible. Remember that you may be working with some of these folks in a few years’ or decades’ time.
  8. Be professional and courteous (I can’t think of a time when this is bad advice, but at moments of transition it is especially important).

Leaving a job is a very personal decision and will impact your career. Spend time thinking about how to leave well, treat everyone with respect and have a plan.

Jobs Lifehack | moore | | Leave a comment

Let AWS RDS handle database scutwork

Amazon DatabasesRDS is a service I’ve mentioned in the past, but it’s fantastic. You can outsource large chunks of database administration to AWS. Tasks you can forget about include backups, failover, read only replicas, and OS and DB upgrades.

This is a great fit for spinning up databases for small scale to large scale systems and prototyping.

Things to keep in mind if you start using RDS:

  • The database is launched into a VPC and will have a security group around it. You’ll need to allow IP addresses or security groups access to the port the database is living on or your connections will time out.
  • The database RDS creates is a normal database that you can manage like you can any other database you have set up and installed, but there are certain limitations (for example, no MySQL UDFs). Read the documentation and understand the limitations, but be aware they are constantly changing. I suggest subscribing to the AWS Database blog RDS category for updates.
  • RDS uses EBS under the covers and has the performance constraints of that technology. For the largest scale production systems you’ll want to test before jumping in whole hog.
  • If you are using MySQL or PostgreSQL and are running into concurrency problems, Aurora may be worth evaluating.
  • If you want to have backups past thirty five days for peace of mind of compliance concerns, you’ll need manual snapshots.
  • RDS only supports certain RDBMS and limits databases to certain sizes. If you want to run anything else on AWS, you will need to self manage your DB on EC2 or look at other data management solutions. Here are some other gotchas.
  • When using RDS you aren’t freed from all database administration tasks. There are still users to manage, indices to add, and queries to tune. Most of your RDBMS skillset is applicable to RDS, however. You’ll also need to determine when to schedule DB and OS upgrades, backups and how to size your instances. You still need to set up the optimal architecture of an RDS system including standbys and read only replicas and do other configuration both at the network and database level.
  • You can manage RDS system attributes via cloudformation, terraform and the CLI in the same way you can manage other AWS infrastructure. That said, the RDS system is stateful so you can’t treat it entirely as “cattle”.

You can learn more about RDS in the extensive documentation.

Amazon RDS AWS Databases | moore | | Leave a comment

Swagger looks pretty good from here

SwaggerA few years ago I was working on an API that my client was going to make available to some of their clients. I used Swagger, which I’d heard about from a Gluecon presentation.

I was unimpressed. I recall having difficulty getting the online tool to work and the documentation generated was poor. This could very well have been user error or my misunderstanding of the sweet spot of the tool, but for whatever reason it wasn’t a fit for the problem.

Fast forward a few years and I was talking to a company about a position. They were planning to use Swagger to generate their API SDKs. They had an API which was crucial to their business and were currently supporting a large number of SDKs on a bespoke basis. I reviewed the documentation of Swagger and downloaded the 2.3 version. I was very quickly able to generate a number of client and server stubs using the codegen project. They have a long list of supported languages, but I quickly generated ruby, csharp and perl client bindings and a simple rails5 and spring server. I didn’t push these through to production and I’m sure that if I had I’d have learned about the rough edges (it’s always nice to check out Stack Overflow for rough edges for any technology–here’s questions for swagger). Regardless, the ability to take a simple JSON configuration file and create API front ends and backends in minutes was quite impressive.

Note that the codegen tools are all in java, so if leveraging that technology gives you the willies, you might want to look around for another solution. Note also that Swagger has now been moved to the OpenAPI project (as of version 2.0 of Swagger). If you want to know more about that, here’s the blog post announcing that move. Here’s a look at features of the next version.

If you are developing an API first company (and there are good reasons to be that), I’d recommend taking a long hard look at Swagger. The speed of adding SDK support as well as the community around this tooling look to be huge advantages.

APIs | moore | | Leave a comment

Blockchain now in the trough of disillusionment?

ChainsLooks like the blockchain may be headed into the trough of disillusionment. See also Kevin Owocki’s thoughts on ICOs.

This happens to every technology. There is wild optimism over the usefulness (remember Iridium?), which is overblown. It even happened in the 1800s with trains. That said, I’m sure there are uses for blockchain technology beyond stores of value, and am looking forward to seeing those emerge. For a fascinating read on the rollout of technology, see The Deployment Age.

Technology and Society | moore | | Leave a comment

Remote work opens up the labor pool

PoolThis tweet from Justin Searls (from TestDouble) discusses how companies who hire remote developers don’t have any issue finding applicants (to the point where they don’t need to pay recruiting fees). This doesn’t surprise me at all. There are a number of reasons why remote work will lead to more job applicants.

  • There’s a larger labor pool. This is the biggest advantage, and accrues to both sides of the labor market. (There’s a larger labor pool, but there’s a larger set of hiring companies as well.) Even if you are in SF, the labor pool for a particular technical skill is going to be larger if you include remote work (because your pool will include everyone in SF as well as everywhere else). If you can handle the legal tangle, your labor pool can extend past national boundaries as well.
  • The remote developer has more time. Typically the “commute” for a remote worker is on the order of minutes or seconds, as they walk to a different room in their house. Compare this with tens of minutes or hours of driving, public transit or biking. A commute to an office is a hidden job expense which can total hours of unpaid labor every week (or you could look at it as the price you pay for living where you want to live, as opposed to where your employer is located).
  • Remote work promotes different, less intrusive communication practices. Meetings take place on slack. PRs are reviewed online, rather than code review happening by looking over someone’s shoulder. Aysnchronous communication is favored (although that can certainly happen within colocated companies as well). These processes are far better for knowledge sharing than anything else, especially as a team scales.
  • Similarly, flow is easier to achieve when you are a remote worker, as long as you turn off your notifications (and set up your office appropriately). Depending on your workload this can be valuable and/or appealing.
  • Remote developers in general have more control over their environments. Most people enjoy this control (which, by the way, is free or cheap to the company).
  • People don’t have to uproot their lives to work for an interesting company.
  • There’s a larger labor pool. This is so important it’s worth listing twice.

There are of course many benefits to being onsite.

  • Easy, free, higher bandwidth communication that doesn’t require downloading yet another video conferencing plugin. Humans have been communicating face to face for hundreds of thousands of years and are finely tuned communication machines. If communication is a wall of text, context can be lost and misunderstanding can ensue.
  • Interaction outside of work is easier. This can be more important for different folks at different times in their career.
  • Water cooler/serendipitous department cross pollination can occur when people are in the same physical space.
  • Some types of technical discussion are just easier in person (I still haven’t find a truly great online whiteboarding application).
  • Some folks have a harder time staying focused or being motivated at home.

There are of course solutions for remote workers for all of the above onsite advantages. Every company and worker needs to determine what works best for them.

But just like e-commerce changed retail and social networks changed keeping in touch with old friends and work colleagues, I expect remote work to remake the modern team organization structure.

PS For more on this, consider this subsequent tweet from Justin.

Jobs Recruiting | moore | | Leave a comment

Ephemeralization is the future

In the same vein as “write less software“, this is a great post about ephemeralization. To ephemeralize software is to make it disappear either by pushing it to another provider or just removing the feature. From the post:

Proposals to ephemeralize a component or feature will sometimes be met with emotionally-charged responses from your team. It’s totally reasonable to feel attached to a component everyone has worked hard on and has been important historically. But realize that the component has value because it got you to where you are today, not necessarily because of its ongoing existence in the future.

Path dependence of software is very real. What you’ve done before determines what you can easily do in the future. But you can take large right turns if you are prepared to make the investment. As the above quote notes, it’s not just an investment in time, knowledge and money, it can also be an emotional investment.

Devops | moore | | Leave a comment

“Run less software”

RunningThis post from the folks at Intercom makes some really good points about the benefits you can get from leveraging other software solutions. It’s an interesting article, but the source works at a company that offers a SaaS solution to help you help your customers (I’m a fan). You can read some interesting discussion at HN. An interesting quote from the post:

Choosing standard technologies is very similar to this, only in software. You need to constrain yourself to solving problems mostly, but not exclusively, with a small, specific set of standard tools. By doing this over time we become experts in them. Then, we are able to build better and faster solutions from them.

From my experience with small teams, having a standard software stack is a big win. It lets you reuse business logic and skills across your business. (The spread of microservices may mean this matters less in the future, though with a small team and product microservices may be overkill.)

However, I wish Rich had titled it “write less software” because that is really what he is advocating for. When I use AWS or Intercom or Gmail, I’m not really running less software. In fact, I may be running more. Since I don’t have insight into those applications, I really don’t know. But I’m not concerned about writing, reading and maintaining as much software, and that is the true win.

Programming | moore | | Leave a comment

AWS Quick Starts

StopwatchIf you are looking to stand up an application quickly, I often recommend the AWS marketplace. This service has thousands of vendor maintained solutions and is a great way to get going quickly. Note that some of the solutions have extra per hour charges, and if that is the case per second billing won’t apply. These solutions are focused on individual AWS EC2 instance images (so you can quickly stand up a phpbb instance or a redmine server, for example).

However, another good option is AWS Quick Starts. These are recipes for deployments, possibly of multiple virtual machines, and are aimed at handling larger business problems. There are over 80 listed on the Quick Start page right now, ranging from creating a data lake to a HIPAA reference architecture to running devops tools like consul and bitbucket. These solutions may or may not carry additional charges, so make sure review licensing and billing information as well as functionality.

If you are thinking about setting up a complex system in AWS, it’s worth some time to see if someone has put a reference Quick Start together. It may not fit your needs perfectly, but can be a good place to begin.

AWS Tips | moore |