eel

I have been making things with masa flour. Tamales, bocoles, tortillas, and pupusas. So far the pupusas are my favorite, and very easy to make. From scratch, I can prep, cook, and eat in less than a hour, so it's ideal for a lunch break.

I agree with you that a lot of skill is transferable between technologies, but I suspect that some recruiters or hiring managers either don't realize that or they typecast you into a specific role. Resumes are a form of writing where being concise is better than being complete.

Also, I should have been more clear. I don't erase everything about a past experience if it's a different technology. Here are a couple hypothetical examples to help clarify. In this first version of a resume snippet, the applicant should be applying for a Java position since it's filled with terms that make sense to the Java community:

> Software Enginer at XXX Company

> * I led the design and implementation of XXX Company's internal payment processing service which processes $YYY million USD in annual revenue. The project used Java, Spring, Hibernate, and MySQL.

> * Introduced testing (JUnit and Mockito) into the engineering culture by leading brown bag talks. Increased unit test coverage on critical company projects from 0% to 73% over 2 years.

> * Used JNI to integrate critical path code with XXX Company's proprietary hardware driver, increasing average performance by 8x.

Here is a snippet representing the same experience, but catered toward a Node.js position. References to enterprise Java are removed, and the last bullet is replaced with a more relevant bullet:

> Software Enginer at XXX Company

> * I led the design and implementation of XXX Company's internal payment processing service which processes $YYY million USD in annual revenue.

> * Introduced testing into the engineering culture by leading brown bag talks. Increased unit test coverage on critical company projects from 0% to 73% over 2 years.

> * During XXX Company's annual hackathon, I implemented and presented a functional prototype service to present payment information in real-time using WebSockets.

Now these changes alone are likely not sufficient to get a call back from the Node.js job position, but it changes the automatic typecast from "experienced Java developer" to "experienced developer" Hopefully this candidate has some other past experience in Node.js/web development/JavaScript to flush out the story.

If I may offer a suggestion, what works for me is that at the start of a job search, I first make a very large resume, with several excess bullet points and detailed lists of technologies. I am the only one that sees this version of my resume. Then, for every job I apply for, I cut out all of the uninteresting bullet points and reduce irrelevant terms for that job description until my resume is about a page long. For instance, if I'm applying for a Node.js role, I minimize my past Java and .NET experience (I may mention each just once to show a little bit of breadth) so that my JavaScript experience shows through more. Likewise, if I apply to a Java role, I minimize my JavaScript experience.

After I apply to a few companies, I can easily reuse resumes with little to no modifications. The goal is to hit as many job requirements in the job description as I have experience for without overwhelming the recruiters and hiring manager with irrelevant information.

I only submit cover letters if they are required, or if I have a unique connection that I can bring up (e.g., having met the hiring manager at a recent meetup).

While I agree with your advice in the general case, I also find the author's data point interesting and compelling. Receiving 2 offers from 7 interviews with only 16 applications is a good rate in software engineering as far as I am aware.

It's also worth pointing out that the cover letter mentioning "rare programmer" ultimately led to an interview and an offer according to the author.

The raw data can be gathered from congress.gov, but here's a summary graphic for 2019: https://en.wikipedia.org/wiki/United_States_federal_budget#/...

It depends on your definitions of entitlements and military, but for example, social security spending was at $1.0 trillion compared to $676 billion for defense.

I'm keeping an eye on initial jobless claims and BLS unemployment statistics. I'm concerned that it's a cascading effort as fewer workers means less spending means less earnings means fewer workers and the cycle continues. Obviously the government has levers to try to ease the pain (lower interest rates, pass stimulus bills), but it's not yet clear how sufficient these levers will be.

I think you have to find what interests you. Think back to the times you were most excited—what was different then?

Personally, when it comes to putting code on the screen I am motivated mostly by two things:

1. I am excited to put a puzzle together. The same thing that makes me interested in finishing a basic puzzle like a sudoku applies to writing code. I want to see my end result work, and putting all the steps together in my code is enough to keep me up late.

2. I am oddly excited about learning and applying best practices. Often I initially solve a problem by mimicking existing patterns. Then I will spend hours pouring over man pages and standard library documentation in order to figure out the best way to do something.

For me, everything else feeds into those two basic motivations. In my career I get to apply those concepts at a larger scale. I'm finding that my motivations extend to domains other than code, both in my career and in my personal life.

I encourage you to reflect and consider the moments when you felt the most joy and the moments when you felt the least joy, and what was different between them.

Good stuff. I think this is a good general template once you've established a relationship with your manager. If the manager is new, I don't expect direct answers to #2 and #3, so I would ask more meta questions-- how they approach career development and feedback, etc. and get them thinking about those topics for future 1:1s.

If I am joining a new team or company and therefore getting a new manager, my 1:1 meetings generally support my onboarding. I would ask about the team's current processes, how they got there, who to ask about learning the system architecture, etc. I also try to get a feel about what the new manager's style is. How does the manager want to stay apprised on my work, what is his/her approach to career development, etc. And very importantly, I ask how often we should have 1:1s.

If the new manager is joining my existing team as my manager, 1:1 meetings now support my manager's onboarding. The topics are very similar, but I have to be a little more tactful to avoid appearing arrogant or patronizing. I will ask what he/she thinks of the product we work on, or about the system architecture. Once again, I will try to get a feel for the manager's management style, and I will ask about the approach to career development and future 1:1s.

In either case, my number one goal early on in 1:1s is to build rapport. I don't intend this as a "winning favor" type of thing, but rather I need to do my best to build the relationship from my side so that I feel comfortable raising concerns and I can understand where my manager is coming from when inevitably he/she starts making new requests.

I don't like to share a 1:1 agenda until it's clear that the manager respects 1:1s. Otherwise there's a risk that the manager preemptively invites other people to help answer the topics in the agenda.

I try not to rant or complain in 1:1s anymore. I found that my managers' reactions were rarely predictable. Some managers try to solve the problem immediately, and some managers do nothing. Some managers would move me onto another project. Now that I have more experience, if I have a complaint, then I also try to propose a solution.

Finally, I try to avoid using 1:1s for status updates or escalating blockers to my manager. In my mind, these are best done as needed or as soon as possible.

How did you make SDE-3?

This is the big surprise to me:

> Finding 2: People want fine-grained controls over the data they share with apps.

While I personally 100% agree, I would have guessed that the vast majority of Google users (i.e., non-HN crowd) wouldn't care about fine-grained controls. I wonder if they found that some people passionately care and most didn't care one way or another. In other words, perhaps the people that click/tap through permissions prompts are going to continue clicking through, but the change could win back some privacy conscious consumers.

The advertising is ridiculous. It used to be that the ads were one or two listings at the top or the bottom of the search results. Now they are top, bottom, side, and mixed in some of my search results and look more similar to non-sponsored listings.

Over the summer I used Prime Video to watch Sneaky Pete, and every episode would start with a 30 second ad for a different Prime show. There was a skip button, but it was hidden, and I could only find it by long tapping.

So I cancelled Prime. I felt silly paying Amazon to display ads at me.

Tekton doesn't make any tools, but source them from other manufacturers. So they have some Taiwanese, some Chinese, and some US made. Most of the pliers and all of the punches come from Wilde, a US manufacturer.

Amazon is the first place I've seen where the core values are useful, clear, and integrated into the culture. For the values to be effective, everyone up to the top has to follow them, and you can see that at Amazon in the annual shareholder letters.

Other companies I've seen ask their HR staff to put some words (e.g., "Entrepreneurship" or "Be bold") on some posters and call it done.

At a previous gig, without getting into specifics, we built a huge internal client-server system. The client was written in Node.js and ran as services on both Windows and Linux on a few thousand machines. The server was written in Node.js and ran as a Linux daemon.

Node.js matched the developers' skill sets and gave us the ability to quickly write a server that could easily handle several thousand concurrent requests from the clients. On the client-side, Node.js gave us cross-platform support for nearly free (as well as being within our skill sets).

Looking back, I do not think the project would have gotten off the ground in any other platform in that specific organizational environment. The server on Linux was particularly well-suited as it was architected to scale horizontally but still had room to scale vertically.

On the client side, while we were able to get the Node.js service out pretty quickly, it eventually had performance and integration issues, particularly on Windows. It was super frustrating having to shell out to external processes or write native C++ modules to get access to some needed Windows APIs. In hindsight, I would have tried to rewrite the Windows client sooner in C++ or C#. On the plus side, it was a huge advantage that the entire Node runtime fit in a single executable (no dependencies on a huge JRE or other runtime).

Overall, I would recommend it as an option to consider if most of the following is true:

* Need to get to market quickly * Application is I/O intensive rather than CPU intensive * Dev team already knows JavaScript * Target environment is not Windows

Personally, I decided to move away from Node.js and these days if I was faced with the same problem I would lean toward a JVM language or Elixir.

In my experience, most recruiters push harder to get a number than the hypothetical conversations in the article. Maybe I'm not as much of a charismatic speaker as some. Fortunately, for the most part, they don't care if the number is your current salary or your expected salary. Generally, they are willing to meet or slightly exceed my current salary, but low ball my expected salary. I much prefer to give an expected salary (of about 10-15% more of my actual expected) than my current salary.

With the availability of Glassdoor and old-fashioned networking, it's really not hard to figure out market prices (at least for software engineers) in an area and company type.

I've tried to follow some of the advice of avoiding/deflecting the salary question, and I think it generally is a poor substitute for being well-informed. It also makes for some extremely awkward conversations when it comes time to negotiate. Maybe it's a personality thing, but I would rather set the upper bound and let them try to negotiate me down rather than letting them set the lower bound and try to negotiate them up.

Is the process state-dependent? Can you only reclaim mines in public lands (and does it matter if it's NF vs BLM?), or can you claim an abandoned mine on private property?

I've wondered if I could shortcut the school requirement on the basis of already having an ABET-accredited computer engineering undergrad. My state does not seem to distinguish the type of engineering education required to be a PE. I would think that a computer PE is not quite the same as a civil/structural PE though.

As for welding, certifications and or even training seems to be very expensive. E.g., a single one-semester (4 credits) welding class at the local community college is $847. I'm tempted to buy some welding equipment from Harbor Freight and just try to learn from YouTube videos (which is basically what I did to teach myself car repair).

I would love to get into structural engineering. I just can't justify the cost of school, and the end salaries are not even going to be better than a software developer's.

Or maybe be an auto mechanic. Or a woodworker/metal worker/welder. Or a farmer (seriously).

Part of me wants to embrace the city and "book" knowledge to further my career, and part of me wants to abandon it and go back to a rural life and just make/repair things.

I quit my job in the spring, took the summer off, and started a new job in the fall.

At my last job, I felt like I was at my growth limit with little left to learn. At my new job, I am currently overwhelmed with a new stack, new tools, and a new culture. Going to put in a little extra time this weekend and coming week to hopefully catch myself up and end the year on a more relaxing note.

I thought I recognized this article. Here is Joel's original answer (2011) on a Stack Exchange site with some comments: https://web.archive.org/web/20130329010105/http://answers.on...

Here is a previous discussion on HN: https://news.ycombinator.com/item?id=2208056

I use a ThinkPad T410 (2010) with i5, 8 GB RAM, and 7200 RPM HDD and a headless Debian server running on an Intel Atom (also circa 2010) with 2 GB RAM and 7200 RPM HDD.

Most of my development is done on the headless server using ssh + tmux + vim, though I will use Visual Studio or gvim on the ThinkPad if my current development is targeting Windows.

This is what I set in my .vimrc today, and it seems to be working pretty well:

  if executable('rg')
    set grepprg=rg\ --no-heading\ --vimgrep
    set grepformat=%f:%l:%c:%m
  endif

Then you can just :grep yourquery (or :grep yourquery path), and the results will show in a quickfix window.

I was a developer at a big corp (financial services industry) until leaving earlier this year. It steadily grew over four years from around one hour a week to five hours a week (~13%) of meetings. My first few weeks had a lot more meetings (trainings), and my last couple weeks had a lot more meetings (knowledge transfer).

Because I became an expert in some areas, I was routinely invited to meetings to give my input (which further reinforced opinions). Furthermore, I realized a lot of non-technical people are not good about responding to emails. If I needed something from a product manager, chances were better that I could get it faster by setting up a 30 minute meeting for the following day. If I needed something from a senior engineer, email was best, of course.

Honestly, given the role I had and the largish size of the company, I never felt like it was too many meetings.

For what it's worth, most tech employers in the Denver area offer the "Ecopass" as an employer-paid employee benefit, which makes the buses, light rail, and call-n-ride free for the employee.

Without any discounts, the cost for the call-n-ride is $2.60 to the rider, which is a good deal for a door-to-door service, I think. I am not sure where the article got the $21-- maybe the city is subsidizing most of the cost.

To me, the impressive thing the China has done is making the technology ubiquitous and commercially successful within China. As a software developer, I don't see a lot of magic in writing applications. I feel confident that I could write a WeChat or a mobile payments platform given enough time. But to convince hundreds of millions of people or thousands of retailers to use it? That is beyond my comprehension.

When I hear about technological prowess, I am expecting things like rockets that land on barges, self driving cars, and even block chains. Not web apps and mobile apps.

China has enough of the pieces in place that I wouldn't be surprised to see some innovations soon that would impress me. But it just hasn't happened yet.

Reliable: vim, Microsoft Word/Excel, SQLite, tmux, GNU coreutils, svn

I think most would agree with most of the items, although svn warrants an explanation. I prefer the paradigm of git, but svn always impresses me with its ability to handle large repositories and large files out of the box without falling over.

I do not understand how the US can charge someone with copyright infringement if that person is not a US citizen and has never been to the US. Is there an international agreement on how to handle infringement? Can Americans be extradited for infringing upon copyrights from other countries?

I would suggest using HTTPS on your main domain. While you do include an iframe from a HTTPS source for the form that asks for a credit card, someone could MITM the main domain and replace the iframe source with something else, and the user might never know.

If your application is a well-behaving application in a well-behaving environment, then it will most likely run in a reasonable amount of time. Furthermore, if you leak a few mutexes, it's not really a big deal for most applications.

I think one of the implied points of the article is that you should not rely on finalizers for anything time sensitive or critical. For instance, if you MUST close a file handle or database connection, you should never rely on a .NET finalizer to do it because it's not predictable when or if it will run. You should explicitly close it (most likely by implementing and calling Dispose().)