bbrunner

The author isn't wrong that "Senior" is probably a bit of an inflation for what it means in the industry - competent enough to work on medium to large projects with little oversight - but Staff, Senior Staff and Principal titles all exist to fill the gap the author is talking about, as does architect, although I don't see that one as often. It's definitely confusing if you aren't intimately familiar with the industry though.

For what it's worth, I can't think of any notable company where senior is anywhere close to the terminal level for a software engineer.

I'm not sure what your environment of choice is, but I use Python with Django which has great built-in email/password auth and a really nice user admin tool[0] if that's all your looking for.

For third-party authentication/authorization, I use the python-social-auth django integration[1]. It has a massive number of third-party systems that it can connect to and it's really simple to get it set up. I would guess your language of choice has similar tools. I know passport[2] for nodejs is a solid choice.

[0] https://docs.djangoproject.com/en/2.1/topics/auth/ [1] https://github.com/python-social-auth/social-app-django [2] http://www.passportjs.org/

Great to see this happen again after the original "The New Deal" in 2014[0]. I'm a big believer in having enough capital to not have to worry about day-to-day costs so you can focus on actually running and growing your business, and this feels like a good sort-of "cost of living" increase.

[0] https://blog.ycombinator.com/the-new-deal/

Thanks for noticing! The templates on the page are adapted from the actual tools in the app. They use sample data that has dates that are updated whenever the page is rendered. It's all cached on the backend so it doesn't end up costing too much extra in load time.

Hey HN, I've been building Intuition as a side project for a few months now to scratch my own itch. I believe that there are a ton of valuable insights sitting in the meta data in Git repositories and developer-focused tools (JIRA, Trello, Slack, etc.). This data largely goes untapped. This is my attempt at unlocking some of that value.

I focused on a couple of specific use cases:

* daily standup reports to replace or augment your existing standup * historical activity reports for sprint retrospectives * code change notifications so you can know when to provide just-in-time feedback

It isn't anything too sophisticated just yet, but I've already gotten a decent amount of value out of the tool in working with my own team.

Thanks for checking it out! Please let me know if you have any questions or feedback. It would also be awesome to hear what sort of reporting you would want to see next.

If you are already in the Bay Area, I would recommend that you probably just stay there unless you don't plan on raising VC. It's certainly not the only place you can start a company, but it is still one of the best places to do it.

In general, the early parts of any startup can be achieved pretty much anywhere. Building product, early customer discovery, marketing, etc. are not really dependent on geography for a large number of tech-focused startups.

Location becomes an issue when:

* you have some physical presence as part of your product (e.g. meal delivery, bike shares)

* you need to hire (unless you a comfortable with remote work)

* you need to build partnerships

* you need to visit clients (this can be solved by being near a major airport)

* you need to raise capital (the terms and availability are typically just a lot better in the bay area and a few other big VC markets)

So yea, if you are in the Bay Area already and you are wanting to build a true, hyper-growth startup, I would suggest that you just stay put since it will be advantageous further down the line.

Hey, I just went through your signup questionnaire to test it out (I work in a similar space in the US). It felt very long to me in comparison with most services I've looked at. I'm not sure what the regulations in Chile require you to ask, but for what it's worth, Betterment entirely skips doing a risk questionnaire and let's you immediately choose a goal/portfolio. The signup funnel for financial services is long and brutal due to all of the PII you have to collect, so making it shorter is usually a big win.

Overall very impressed though! Awesome to see this sort of stuff launching in markets outside of the US.

This seems like a poor choice of technology rather than an outright nefarious decision. Polymer [0] uses the shadow dom api [1] extensively, but shadow dom v1 still isn't fully implemented across all vendors and shadow dom v0 is deprecated and slated for removal in April 2019 [2].

This feels more or less like some premature dogfooding of Polymer. It probably would've been advisable to serve the old version until modern non-Chrome browsers caught up, but Shadow DOM v1 will be implemented eventually so my guess is they made the decision to transition those users now.

[0] https://www.polymer-project.org/

[1] https://www.polymer-project.org/3.0/docs/devguide/shadow-dom

[2] https://www.chromestatus.com/feature/4507242028072960

Tell the product owner what the situation is and collaboratively come up with either:

a) a new timeline that you believe you can meet or b) a list of tradeoffs that can be made to get the project out the door in time

I have been an engineering lead and a product manager and it is much better for everyone to just be upfront about all of this.

You know what your team can produce and (roughly) how fast they can produce within an order of magnitude time-wise. The product owner should know what stakeholders actually want product-wise and what an acceptable timeline looks like. You should be able to work together to narrow the scope of what is being worked on to a point where your team can accomplish it within the timeframe.

Communication and setting expectations are key. This needs to be done both up front and on an on-going basis. As an engineering manager, you should be able to evaluate, week-to-week, where things stand and which tasks may need to be cut to make a deadline or how far a deadline should be pushed back if things can't be cut. Your product owner should be able to weigh in on this and should already be prepared to pare down requirements if necessary.

It may be painful and embarrassing to start having these conversations now, but it is significantly less painful and embarrassing than having these conversations in 3 months when the product is expected to be delivered.

For the sake of adding to my own discussion, my issues (specific to AWS) were:

1. Installing dependencies became complicated. When Chalice worked, it was great. Certain dependencies (in my case lxml) required a precompiled bundle that someone had thankfully already taken care of packaging.

2. Visibility into the process was poor. It felt hard to get into the system and really introspect it once it was deployed.

3. I felt pushed to other "serverless" solutions within AWS that I wasn't comfortable with. I understand the inherent vendor lock-in with the current serverless offerings, but I felt like I was doubly locked in when e.g. the "best" choice for a db was Amazon Dynamo.

4. Current serverless frameworks feel very minimal. I'm a big fan of both Django (batteries included) and Express (bring everything on your own). The tech that is out there now feels like Express, except that there isn't a lot of extensions to layer on top. You sort of have to cobble your own together still.

5. Lack of Best Practices. I just didn't see a ton of thought leadership on how to do things the right way in a serverless environment. I might have just missed this though.

----

Overall, I've come away impressed but I feel like building something entirely on serverless isn't quite as fleshed out as it needs to be yet. I think it's very close though.

I would agree it's over-exaggerated. In my day to day work, the GIL has rarely, if ever, been the performance bottleneck. It usually traces back to something outside of Python (e.g. a slow DB query or a slow API call) or to something that has been implemented in python in an inefficient way (e.g. writing something O(n^2) when if you read your algos 101 book or even just searched stack overflow you could find an O(n) solution).

I also think that the whole "drop down to C argument" is sometimes viewed as a cop-out when criticizing python, but I personally believe that being proficient at high-level and low-level languages, knowing their strengths and weaknesses, and transitioning between them when it makes sense is stronger than just using purely high OR low-level. It's sort of like having multiple gears on a car: you need all of them, and they are all useful and most opportune in different scenarios.

To me, the core points seem like table stakes knowledge that one should have before jumping into development with ANY language, not just Python. Every language is a tool that is good at some things and not good at others. Cue the standard if all you have is a hammer, every problem looks like a nail.

A few core things:

The GIL problem is frustrating. I generally just try to avoid writing threaded code and instead execute calls asynchronously or run parallel instances and work with Celery or something similar. For web applications, this tends to work well enough for me personally but this is definitely a valid issue.

Python2 vs Python3 is sort of a done deal at this point, in my opinion. I was a big holdout on moving to 3 for a while but, for the past couple of years, I haven't had more than 1 or 2 cases where I had serious issues. I don't have to deal with legacy codebases though.

On a larger note, I would say that this all points to the fact that it is easy to do things the "wrong way" in Python. The accessibility of the language is great, but it is not without its issues if you go in expecting it to be a fenced-in playground with batteries included (to mix metaphors).

I think the base use case of Docker is still relatively simple, although like all things it has gotten to the point where, if you want to dig deep, you definitely can get way into the weeds, especially when you start talking about networking, orchestration, composing containers, and all of the tooling that now exists on top of Docker.

When you choose Docker/containers, you make a choice to expose yourself to a distinct class of problems. You make a tradeoff of saving overhead in exchange for opening up other issues. This isn't an absolute good or bad thing, as sometimes shaving off overhead is worth it even if your failure case becomes much worse.

I will say that, in general, I've found a lot people don't make this type of consideration and just go with a dogma of "Just use {technology} because it's popular".

This feels a bit like "Why use Dropbox when rsync exists?" type of argument. Sure, you can do everything docker does with shell scripts, and you've been able to for decades, but many people didn't, because it was "complicated". There is often a huge amount of value in simplifying things, even if it means losing some of the power and the end result being objectively worse.

In general, anything that is a red flag is probably something I would just clarify in a 20 minute phone screen. Most of the time, what looks like a red flag on a resume has a good explanation. That being said, the two that come to mind that I've seen the most of are:

- Not taking direct ownership of achievements (e.g. I was part of a team that did x). I don't care what your team did, I care what you did even if it's less impressive.

- Recent Coding Bootcamps. Not necessarily a no go, but I've had very mixed results with this one, some good, some bad. This will probably get me to look at what you did prior to software development and evaluate if you are a capable person in general.

I've been using redis + resque[1] for a few side projects and I have to say I'm glad that streams are getting first class support in redis. I was always a little wary of hacking this sort of functionality on top of redis lists. It worked, but it sort of seemed a little bit fragile.

[1] https://github.com/resque/resque

The default behavior is less than great, but it's serviceable at the very least. It would be nice if they tried to be a little smarter and took the background-color of any full-width elements and stretched that out into the insets.

I frankly thought it was going to be a bit more of a mess than this so I'm pleasantly surprised.

I really enjoy GitLab. Very easy to setup and does what it promises. I will say that it's slower than I would expect but I haven't found that to be a deal breaker for me personally. Probably depends on your workflow and how much you do locally vs. in the UI.

Yea I wish it was possible. The read/write repo permission is the only way I've found to be able to list all of the private repositories in an org. There's a few other threads in these comments that cover the specifics a little bit better but the gist is that GitHub has pretty coarse grained permissions unfortunately.

I agree! There is a ton of awesome information just waiting to be uncovered. Diffmatic currently just sends out a really raw digest but getting smart about surfacing meaningful and important changes would be huge. I think that incorporating sources like sentry and other exception trackers and correlating them back to code changes in the digest would be very interesting and useful.

I'm able to access repos for organizations I'm not an admin for. That's very strange.

I'll have to look into it. Feel free to hit me up at hello@diffmatic.com with your account info and I'll see what I can do.

It's repackaged according to person and repo and in your inbox every day. I'm also working on joining it with other data sources (trello, jira, sentry, etc.) to make it more holistic.

I tried repo:status but from my testing I wasn't able to list private repos. So even though I might be able to get their commits I had no way of discovering all of the private repos for a person/org.

I'll reinvestigate this as soon as I'm off the caltrain and have decent internet :)

Unfortunately, as far as I can tell, there isn't any way to specifically ask for only read permissions for private repos. The commit statuses permission doesn't allow for listing of private repos either.

If I'm completely missing something than I'd be more than happy to get a change deployed.

I'd love to support other providers (BitBucket) and have generic Git support. This is a quick first pass since GitHub comes built in to python-social-auth and their API is really well documented and has good python wrappers.

I think it'd be interesting to have a daemon sitting on devs' computers that could track unpushed commits or even in-progress code. It might be a little bit intrusive but I think that having more insight could be really neat.

Hey, developer here. Made this in my spare time to get reacquainted with django and to learn how to use celery and celery beat. I also love the idea of using data that people are already creating passively in a new way that breathes some more use into it (e.g. using github commits to give a daily status update).

Thanks for checking it out!

It's interesting that this is inside of the computer science department and is limited to engineering students considering YC has really been expanding the companies it's accepting. E145[0], an existing and highly sought after technology entrepreneurship course, is just a general engineering class and isn't limited to traditional engineering majors, as far as I'm aware.

Tons of great founders of tech companies come from disciplines outside of engineering and manage to learn enough on their own. I would wonder if it's a function of keeping it from getting oversubscribed or possibly a way to allow the curriculum to be narrowly focused towards how to build a scalable software business.

Exciting stuff regardless!

[0] http://e145.stanford.edu/

You are potentially going to be business-marrying this person for the next decade of your life. Founder Dating can be a good way to find people who are interested in starting a company, so you can be on the same page about that at least. But, like real dating, you probably don't want to just jump in and commit to starting a company with someone just because they are available.

You need a combination of wanting the same thing (to build a successful company) and being able to tolerate each other for the next few years, both through good and bad. Founder Dating is not a bad way to meet people (and, as an aside, I've seen lots of good founding teams meet at hackathons, too). But, really, get to know someone first. Do a side project or two with them. Hell, just try to become good friends.

Make sure that you know you can work with them when things are great and also work with them when you fuck up big time.

Redshift is an especially limited SQL engine considering it doesn't support UDFs. It is wicked fast, but what you get in speed you lose in flexibility. Current (well, February, but fairly current) benchmarks[0] place Impala and Shark (SQL on top of Spark) within grasp of Redshift while pulling data from disk and, for certain workloads, on par or faster than Redshift. This is without using a columnar file format.

Impala is impressive technology, but it does require you to run dedicated Impala daemons as it doesn't use map reduce under the hood. Shark is especially interesting, however, because it is fast AND build on top of spark, so you can run raw Spark jobs, SQL queries, graph processing and ML all on the same cluster. Shark currently uses Hive to generate it's query plans, but the Spark project is working on implementing it's own SQL engine called Catalyst[1] that promises to be a significant improvement.

[0] https://amplab.cs.berkeley.edu/benchmark/

[1] https://spark-summit.org/talk/armbrust-catalyst-a-query-opti...

I'd like to see this same sort of thing done with updates for the lower 2014 pricing and in either the US West Oregon Region or the US East Region instead of Northern California. NorCal is roughly 10% more costly for many instance types.

Edit: And a little more attention paid to cost of maintenance and outages, which does factor into the decision of self-hosted vs AWS quite heavily. This article sort of does some hand-waving to get away from it, but it is an important consideration.