avitzurel

Another thing, don't expect to create a website (for yourself) and have customers come to you. Not even with Google of FB ads. Go you them!

This is a cold-calling, customer facing, convincing business. It's ads in local papers, flyers and talking to people.

You don't give a CMS, you talk to them where they are, on the phone, WhatsApp, anything. You give them customer service where customer service is completely dead.

Here are my thoughts:

I am far from my days of "building websites", but I built one as a favor for a friend just this week (simple contact form, single page). I was talking to him over the phone about his previous website, how it was built, who built it, etc...

I think there is A LOT of money to be made with building websites for small businesses.

Yes, the challenge is not technical, and yes, we (from an engineering point of view) think it's a commodity and that Wix and the likes are solving all the problems, that's wrong!

Let's start from the bottom, if you have real sales, that talk to small business and take care of their online presence, you will get a lot of business.

Forget about the CMS, forget about the self-serve, you act as the technical person and take care of:

1. Yelp Page 2. Facebook Page 3. Instagram Page 4. Website 5. Content writing

You can get a ton of business with targeting the right business types and pricing it right.

You have to figure out the problem you are solving. forget SEO and forget everything that we as engineers think about, think about the value you are adding to a small business.

If you tell a busy business owner that he can text you the updates they want, or you call them once a week and get a few new photos that you will update in the right places and get them more business, you will thrive.

If you develop a high-touch business in a market where everybody thinks they will win with a low-touch 5$ a month market, you can win.

My friend paid 3K$ for his previous website.

Yes. We rolled our own. We’re always looking to open source, trying to find the resources

Great question

commitbot and mergebot both go through CI first and are linked to the github health checks.

Mergebot will not merge a PR if it fails the tests, commitbot only generates the PR (which goes through tests like any other commit).

bots are automatically deployed via github too. They are just lambda function behind an API gateway.

The library that interfaces with the bots is the same thing, once it's updated ALL of the builds will automatically use that latest version.

It's not that PR are useless at all. This library has our most important code since it's used across all apps.

However, the JSON definitions are just not that important, that's a fact, we can ping engineers and have them lose focus just to get approve or we can decide to automatically approve if it's under directory "X".

I would argue that we did not implement a monolith at all, we just have a faster cadence to update dependency than most.

With the way this works, you can't forget anything and this is why this automation is so powerful, if you change the SDK, you know that everything using this SDK is updated with the latest code. It will either fail tests immediately or you can just move on with your life and focus on more important things

I don't have anything written up in a blog post.

I try to work on soft skills during the interview, I found those to be way more important than knowing to invert a tree.

How does one converse through a problem? How would you go about solving this bug.

I usually do something really simple like

logMessage(from, to, content) {} searchMessageBySender(senderName) {} getMessages() {}

Have the candidate fill in the interface and walk through what the choices are and what are the ups/downs of their solution.

Did you solve the problem using a list of words you needed to find in a long string like "cowsgoformoosomethingelse"?

I really dislike the fact that you need to study for weeks with specific questions that really have no hold in real life.

I've been doing this for 16+ years and I have never asked the type of questions you encounter in these books. Not even once.

We have a close friend who's been fired after just a month on the job. Basically, everyone that was hired with her has been fired on the spot.

Hire fast and fire fast is good as a slogan perhaps but there are people lives at stake here. I don't understand why companies hire 100 people and fire them a month later, didn't they know it's coming?

We use confluence. It integrates with Jira and SAML so we have all of our users in there and it's really convenient to mention a ticket number or a team member and have it automatically import the details.

The main point that confluence does really poorly (for me) is the lack of an external editor and the absolutely shameful support for Markdown.

If I could edit the page with git like interface and an external editor (like you can do on Github), it would be absolutely amazing and would make it a killer product for us.

Moving to another solution without deep integration to confluence/Jira is not possible since those are being used by product as well.

How do you comment on PRs for code review? What do you use for opening PRs?

I have been doing DevOps since before it had a name.

Been running on AWS for the better part of 8 years now and running multiple production environments for clients and as an employee.

Over the years, I have seen the term "DevOps" slapped on so many things I don't even know what it means anymore.

For some, it's a culture, for some, it's a team, for some, it's a role.

SRE is now getting the same treatment. No idea what it means most of the time.

I did not read the article to the end (I plan to). It's mostly good and I agree with the point it's making.

However, I think we need to flip it on its head. From my point of view as an engineer, your pipeline doesn't really matter, no matter how smart and well thought out it is.

The weakest link in the pipeline is what isn't mentioned here, how do you get candidates into the pipeline.

I get 5-10 recruiting emails a week and about the same number of linked-in messages, none of them ever even come to a phone call. (and yes, I have gotten a few from Stripe as well).

How do you email/call/text candidates? How do you define them? Do you have the same email for all or you distinguish between levels?

A lof of companies have a good pipeline and they say "we don't do whiteboards" but their recruiters are doing a disgusting job at finding people, just absolutely shameful.

1) Not true. GraphQL can work with GET and you can have cached queries (to avoid the query string length).

This means, you can cache and you can do whatever you want with caching rules (source: We are running it in production for a long time)

2) This is largely up to you. You can have it as a thin skin or you can rely more on your server side logic.

For us, we chose to have the frontend only handle presentation logic, the rest is handled on the server side.

For example, a lot of our stuff relied heavily on ACL, the frontend needs to expect to NOT get any data on specific fields, that's the only responsible for it. The rest is on the server side.

I think what this is solving is that in case you already have an ALB, you can have a route rule that will direct traffic to lambda. That's pretty powerful.

One thing that I find to be ridiculous with companies (especially at an early stage) is that they have tactics but no strategy.

They try something for a week, it doesn't work, and they move on.

OP here, for example, has an article about selling through Quora. It might not be up your alley, that's fine; If you decide to do it in your company, have someone actively work on it on a weekly basis, develop a strategy for the point you are trying to get across and nail down the message. Don't answer a single question and look at your Google analytics trying to see how much traffic you got from it. Do it consistently until you either figure out it works (or not, of course).

If you decide to sell to decision makes, this should be your strategy, you can't decide today you are selling to X and tomorrow you are selling to Y.

When you make a decision like this, inform the product managers, they now need to build different things. Be honest and be vigilant about it.

Wasn't you :)

But I am now actively looking at it.

I find "What is the value we are getting?" to be the absolute most crucial question.

We were paying a few K$ a month for DataDog. The value we were getting from it was quantified. We evaluated how long it will take to build the features we are using from DD ourselves. It took about a month and we cut them off completely from our stack.

If you take the AWS approach, you have to keep providing value and you have to keep getting your users to buy-in.

I don't know if there's a very good way to actually communicate with all of your users, emails you get seem to mechanical and artificial. "What can we do better?" type of emails don't really work.

On your "manage the saas", did you see https://toriihq.com/ ?

I feel you can also sell from the bottom.

Slack, for example, a lot of the requests came from engineers to work with it.

The product has to be REALLY good though, for most, this is a very hard sell

You also have to know your audience.

storytime:

We had a demo scheduled with a company. We were shopping for a security auditing system for dependencies across all GitHub repositories.

The person going through the demo did an absolutely terrible job at reading the room and understanding who they sell to (right now). Focused a lot on reporting, compliance while we cared more about the mechanics.

Enterprise or no, I see a lot of developers (and entrepreneurs) take the approach of "If you build it, they will come".

That is just not true in most cases.

We all know these products with elaborate dashboards, too much reporting, too many data points. Those are created simply to appeal for the decision makers.

You sell to developers by a better UX/UI and workflow, you sell to decision makers by telling them how they will get a better view of things and manage teams better.

You have to build both ends, and you have to sell the decision making end much better and much more aggressively.

Edit: typos

Yes. You have two good options

Google maps has a bike option. It gives the safest route it can find

Strava route planning uses other people rides as a source of information. You can also explore activities in your area and see what people are doing.

Good luck and stay safe!

I actually think I am very fortunate TBH. I usually do the 30mi route through Portolla Valley in 1:30-1:45. During the summer it is the perfect commute.

If i go the direct route during rush hours I am faster with the bike than any other means of transport.

Honestly, I am surprised not more people do it. With electric bike now, yiu can be flying. Even at my best effort, i can only keep up with the ebikes for a couple of minutes

I'm not saying it's long, but it's a lot of steps that I don't want to deal with in the morning. Prepping everything the night before makes it so I don't forget anything.

For example, my first weeks in the new company I kept forgetting my entry card, now I put it in the same place every day as I arrive home, didn't forget it in months.

This is like filling gas in your car every single day.

Have you seen this: http://www.sf2g.com/?

I would love to experience HWY9, Skyline, OLH, and others from 20 years ago.

The way this works (on these routes)

The shortest route is the busiest in terms of traffic.

The longer ones are scenic, less cars for most parts, no traffic lights and much better workout.

The mid-range one is the one I like using the most, I get to do a lot of speed work and work on my sustained power.