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.
Over here it's mostly just the tech companies that do Staff+ titling.
The oher big organizations, home-grown agencies and similar, usually go from junior and medior to senior. Juniors aren't hired, because "what we do is too complex for them".
After senior you sometimes have an architect role, and sometimes even a senior architect, but that's about it for ICs. Architects are generally not expected to code, or even know how to code. It's more about landscapes of applications.
In practice, senior engineer is a terminal level, though I don't think these companies ever really made a considered choice regarding terminal levels. Up or out would run into problems with employment law very quickly after two years, so it's not a policy that will work well here.
People looking for raises can get them. There's a band for salaries and people can get a few percent raise for performance. Always too little of course. In general, once you reach the end of senior you can eiter do lead or management functions, or do the architect thing, or leave to be a rent-a-dev. Though employment law has recently made that last one harder, due to union pressure.
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.
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.
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.
Thanks! well even though the answer is 'yes the law does require a risk questionnaire' what we've seen with our users is that they actually enjoy answering these questions about themselves. Almost like personality quiz or something ;)
You might still be right though, I guess once we get a wider upper funnel we will be able to test this further.
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.
How can you ever know someone's intent? I don't think it makes sense to assume malice in this case.
- Because YT makes money on eyeballs and runs on every terrible device specific browser under the sun. Making users experience worse intentionally only really hurts them.
- Because we're in a forum of devs that are all about chasing the latest features and polyfilling everywhere that doesn't have them -- it's practically SOP. I totally believe performance problems like this wouldn't get caught in testing when everyone has a corp network connection and powerful laptops/workstations.
I read a really good take once that I can't find anymore, but the gist was: sometimes a company knows about a poor decision or a bug, and just leaves it in because it gives them a competitive edge.
Deliberately and knowingly made decision that hurts already barely existing competition is not an innocent polyfill mistake. It's more like policy level abuse of dominant position to transition users to Chrome from non-Chrome browsers.
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.
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.