Periodically, web hyperlinks in Slack would stop working.

The fix is surprisingly quite simple: Restart Google Chrome.

The best way to restart Google Chrome safely and preserve your current open tabs is to type into the address bar:

chrome://restart

Yes, there is a huge engineering talent shortage in Silicon Valley. There are more companies trying to build disruptive technology that have greater hiring needs than the available supply of engineering talent.

I currently work at Iterable, and we are as of present a Series B company with around $30M raised total. We get hundreds of applicants a week, but few of them are qualified enough. I joined as the 3rd engineer of the company and now we are around 20 engineers; virtually every single engineering hire on our team has been an internal referral.

A company like Iterable is able to reward any qualified engineer quite handsomely; but for these top candidates, they are often like the proverbial kid-in-a-candy-shop and are highly sought after by multiple companies working on the most exciting, cutting edge technologies.

Iterable is poised to be a unicorn or deca-corn some day, as we are quickly becoming one of the essential, best-in-class tools for omni-channel growth marketing automation.

I love to reason and explain concepts using analogies. If you look at the world of professional sports, such as basketball or baseball, you will know that it seems every year, only a few teams consistently make it to the playoffs, semi-finals, and then finals. The teams that make it to the post-season are a small fraction of the total number of teams in the league; an even smaller fraction are serious championship contenders.

If you equate working at a software company in Silicon Valley to being an athlete that makes it to the MLB or NBA, then you will have a very good idea of what people are talking about when it comes to shortage of engineering talent. Many players are simply happy and consider it to be a life achievement to make it to the pro-leagues; only some of the players who are the hungriest and want to achieve greater success are willing to put in the hard work and dedication to reach the upper echelons of the game—whether it be basketball, or baseball, or software engineering.

Furthermore, just as you have specialist positions in basketball, the same also applies to software companies. To be a championship contender (e.g. IPO, $1B+ exit, etc), you need the absolute best, top-notch talent in each position — backend engineers, frontend engineers, infrastructure engineers, security engineers, mobile engineers, etc, and finding top notch talent to fill each of these positions is quite challenging and difficult. It takes years and years to hone and finely tune the skills in any particular area, such that for any position, there are only a few candidates who possess the skills, and then even fewer who are available and not already committed to another team, or working on their own startup.

Hence, it is quite safe to say that there is a huge shortage of engineering talent in Silicon Valley.

Edit:

Initially I did not think to make this a “recruiting” pitch for Iterable (seriously), but just to give an idea of how good we have it, here are some of our perks:

• Free lunches every day, catered by Zesty, from a variety of top eateries in San Francisco. Fridays we can eat out anywhere, with the team, and just Expensify it. On several occasions we’ve eaten at places where it cost more than $30 per head.
• Quarterly stipend of $300 for personal / professional development — I use it to buy books, audio books, and an Audible subscription — for any employee, not just engineers.
• Monthly stipend of $160 for gym membership. I use it for gym membership and workout sessions with a personal trainer — for all employees.
• Quarterly team off-sites — this past week we did an escape room as an engineering team, for team bonding
• Semi-annual (twice a year) company outings — an annual sailing trip on the San Francisco Bay, and an all-expenses-paid company retreat (we went to Bodega Bay this past year)
• Monthly all-hands and office happy hour with lots of beer and delicious food. I don’t really drink, and there are lots of non-alcoholic options
• Fully stocked kitchen, refrigerators, and snacks with fresh fruit, kombucha, Stumptown coffee, Quest protein bars, Krave beef jerky, Tcho chocolate, etc luxurious snacks
• Expense ANY computer hardware, monitors, or desktop equipment. Some of my teammates have dual 34″ ultra widescreen curved monitors and $300 mechanical ergonomic keyboards and vertical mice
• Expense ANY resources needed (software, IDE, books)
• Flexible vacation, flexible hours, and flexible location (remote)
• Interesting guest speakers and world-class learning opportunities — the former CEO of Twitter, Dick Costolo, came in for a fireside chat

Here are some photos from the above mentioned team outings: Iterable

Even with all of these amazing perks, not to mention being able to work with some of the top minds and high achievers in the industry, we have been having such a hard time finding engineers that meet our bar for good talent and good culture and team players (you see, just like in sports, sometimes you have superstar athletes who are not team players, and these would be simply toxic to your organization).

Iterable is currently ranked at #1 on the SaaS1000.

If you’re out there, would you please DM me?

Edited Oct 27, 2017:

Someone just shared this article with me that describes the housing crisis not just in Silicon Valley, but in all of California: https://www.bisnow.com/national/…

There is a severe engineering talent shortage in Silicon Valley, and that goes hand-in-hand with the housing shortage in California.

View original question on Quora

By Jonathan Tsai (@jontsai | https://linkedin.com/in/jontsai)

Original Permalink (working Quip doc) : Communicating with Engineers: How to File Good JIRA Tickets
License: CC BY 3.0

This article was originally written as part of a mini-training for the customer success team at Iterable in July 2017. For the most updated version of this article, view the Quip version at the above permalink.

Edit: This article also got published on the GoodAudience Blog.

Purpose

“Those who fail to learn from history are doomed to repeat it.” - George Santayana

Engineers build things, and also fix stuff when things break. Everyone’s time is valuable, so how can we effectively capture and document issues that come up, so that we make the product better, and learn as a team rather than “repeat the mistakes of history.”

Common Pitfalls to Avoid

• Conflating issues (that shouldn’t be conflated)
  • Symptoms:
    • Combining multiple issues into one JIRA ticket.
    • This is happening for me, too!
  • Why it happens: Upon initial inspection or cursory examination, two or more issues can appear to have the same cause. However
  • How this hurts: If all reported under one issue, we may solve one problem but unintentionally overlook others that got masked.
  • Recent examples: Emails being sent out slowly for Spotify
  • Actual root causes: Three separate issues, actually, with 3 different solutions
    • CloudAMQP memory failure
    • Unhandled exception in our messaging dequeuing code causes processor
    • Inadvertently downgraded date-timezone library dependency, which failed to parse a particular timezone
  • Recommended alternative courses of action:
    • Do some research to pinpoint when (time), where (context: app? mobile? API?), and how (what the user was doing)
    • Capture the major themes
• Prematurely filing a ticket / fragmenting tickets (opposite of conflating issues)
  • Symptoms:
    • You’re filing too many tickets
    • The rate at which you open tickets far exceeds the rate at which they get closed or completed (optimal ratio is hard to specify, but maybe 3:1 or 5:1, but not definitely 10:1 or 20:1)
    • The ticket has already previously been filed
  • Why this happens:
    • Want to avoid conflating issues
    • Did not research if an existing known issue
    • Did not consult or check with other teammates
  • How this hurts:
    • Too many issues get logged, but never worked on.
    • Generates a lot of noise and distraction
  • Recommended alternative courses of action:
    • Talk to teammates and if at least 1 or 2 other CS persons agree it should be a ticket, or 1 other engineer, then file it
    • Do some research whether an existing ticket already exists. This may take more than a basic search or two. Scan through past 2 weeks at least, and search a couple of most likely specific keywords.
    • When it does happen, find the other ticket, enhance the ticket with more detail, and resolve one as duplicate.
• Providing too much detail.
  • Symptoms: Parroting the exact request from the customer
  • Why it happens: You feel inundated or overwhelmed with customer requests, so you report them in JIRA or to an engineering Slack channel for assistance
  • How this hurts: CS is the first line of defense for engineering team, otherwise engineers wouldn’t be able to focus on making stuff better and spend most of the time troubleshooting. Engineers aren’t necessarily better problem solvers than CS, so they would start to feel inundated or overwhelmed, too. The engineer would have to
  • Recommended alternative courses of action:
    • Imagine you are a 911 operator/dispatcher. How would you field calls?
    • Do some translation or summarization of the actual issues at hand. No need to provide a diagnosis
    • Perform some high-level filtering, triaging, and pattern matching before filing a JIRA ticket or hitting up Slack channel
    • Ask a teammate or someone in person (counter-intuitive, yes, but a poorly researched JIRA ticket or Slack message disrupts more people, since N individuals need to read and process that message); an alternate could be using Direct Messages in Slack over blasting a channel.
• Providing too little detail
  • Symptoms:
    • JIRA ticket is really short, or took you less than 10 minutes to create.
    • Engineer follows up with more questions. You answer some questions, and more questions are asked.
  • How this hurts:
    • And endless cycle of questions with no further clarity being established.
    • Or, the JIRA ticket never gets addressed at all, because it wasn’t actionable.
  • Recommended alternative courses of action: A good JIRA ticket:
    • Should take at least 5, maybe 10-15 minutes to create, if not longer
    • Is comprehensible by any engineer
    • Actionable. The problem is succinctly described, and it is clear what the next steps are.
    • Tracks only one issue or actionable item. Only has “one user story.”
• Not filing a ticket
  • Symptoms:
    • You have lots of conversations about an issue.
    • You’ve already spent 20-30 minutes thinking or talking about an issue
    • You’ve already spent 20-60 minutes trying to address and issue on your own, and it is still not resolved
  • Why this happens:
    • You get caught up in the moment or simply forget
    • Not wanting to file too many tickets
  • Recommended alternative courses of action:
    • File a ticket!
    • Include a good title. A good title describes a course of action, rather than the symptom of the problem. Focus on solution, rather than the problem
    • Include a good description.
      • One sentence summary that answers several of “Who? What? When? Where? Why? How?”
      • A short 2-4 sentence paragraph of the expanded problem and proposed solution
      • Any supporting details in a bulleted list
        • Links to the actual issue in the product or app
        • Links to customer conversations, Slack conversations
        • Links to supporting documentation
      • Additional attachments, key snippets of conversations or key pieces of “evidence” gathered or research performed, or troubleshooting steps already taken

Choosing Good Titles

This is one of the MOST IMPORTANT things you can do. You may not think it, but software engineers spend a lot of time reading every day. Reading code, reading tickets, reading Slack, etc. Therefore, choosing a good title for the ticket will have significant effect on comprehension and speed of delivery.

A good title:

• Describes a course of action, rather than the symptom of the problem
• Describes the MVP. Some people like to write user stories, but I’m not a fan.
• Usually starts with a verb, stated in the form of an imperative, as if authoritative:
  • Simply, “Do this” is much preferred to “Can you do this because So and So needs this or that?”
  • This is not rude; it’s succinct and to the point
  • The reasoning and background should go in the description.
  • Engineers can push back or discourse on it in the comments, with their own reasoning
• Important: No verb implies no action, and therefore, none will be taken.
• JIRA ticket titles should not be nouns, generally.
  • For new features:
    • Bad: Facebook Custom Audiences
    • Good: Implement Facebook Custom Audiences
  • For improvement or requests:
    • Bad: IP Whitelisting
    • Verbose: Customer X is asking for a set of IPs or an IP range that they can whitelist when it comes to receiving webhook posts
    • Good: Provide Fixed IPs for Webhook Servers for Customers to Whitelist

Software engineers frequently have to deal with JSON and inspect or manipulate it.

There are two easy ways of pretty-printing JSON from command-line to aid in visual inspection. The first requires no installation, and the second requires a minimal installation but also provides syntax highlighting and manipulation capabilities.

Method 1: Using Python - Nothing to Install

Optional: Add alias to .bashrc
alias json='python -mjson.tool'

Example:

$ echo '{"cool": { "story" : { "bro" : [1, 2, 3] } } }' | json
{
    "cool": {
        "story": {
            "bro": [
                1,
                2,
                3,
            ]
        }
    }
}

Reference: http://www.restlessprogrammer.com/2013/03/how-to-pretty-print-json-from-command.html

Method 2: Using JQ - Minimal Install

Mac install via Homebrew: brew install jq
Ubuntu install apt: sudo apt-get install jq

$ echo '{"cool": { "story" : { "bro" : [1, 2, 3] } } }' | jq .
{
    "cool": {
        "story": {
            "bro": [
                1,
                2,
                3
            ]
        }
    }
}

Reference: https://stedolan.github.io/jq/

I know of several people who start learning to code in their mid 20’s, and are doing fine now.

However, it’s very subjective what a “good living” is.

Compared to the rest of society, programmers (anyone who writes code) and software engineers (a subset of programmers, with more emphasis on “engineer”) might make a relatively higher salary.

However, just as with any field, there are different grade levels, and how well you do depends on what level you are able to attain, and that has a correlation to how much time you spend working on your craft.

If you work hard and dedicate yourself to software engineering now, you can probably make a decent living in 2–3 years. Whether that will exceed your earning capacity in whatever other endeavors you may try, or are currently in, varies widely depending on your individual background, circumstances, opportunities, and experiences (and ability to grow in all of those).

I think it may take 10–20 years of smart and hard work to get to the top tier of any field, software engineering included.

If you’re able to keep your head down and stay focused, go for it. If you’re easily distracted by others around you and are discouraged by others who seemingly effortlessly have more success than you, this may not be the path for you.

I have one friend who was working in the field of tech and executive recruiting, who was considering a switch to software engineering when he was already in his early thirties. I quoted to him a proverb, “Do you see a man skilled in his work? He will stand before kings; He will not stand before obscure men,” and he decided to stay the course and excel in what he was already good at. Fast-forward two years and he’s now crushing it as an executive recruiter, making much more impact than he would have, compared to if he had switched his career to software engineering.

View original question on Quora