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.
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.
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.
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.
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.