amirathi

This is fantastic practical advice for software engineers early in their career. Here's some more based on the common pitfalls I see,

- Don't apply to 50+ companies at one go thinking only a % of them will call you. Choose ~5 companies, do a lot of homework about their business & write to key people at these places telling in ONE paragraph what you can do for their business. If it fails, choose next ~5 and so on.

- Other things being equal choose team over company. E.g. working at core technology or customer facing team at a less-known growing business is much better than working at some internal tools team in Google. FAANG carries some brand value for future recruiters, VCs but you should really optimize learning rate early in your career.

Can someone please summarize the core issues between SO the company & the community?

I see lot of references to policy changes, lack of empathy & such. But would like to know exactly what actions by the company caused this stir.

Go for either,

A. Best possible salary you can fetch anywhere with low equity (around ~1%)

B. Just enough salary to get by with high equity (around ~4%)

Don't get stuck in the middle, avg salary with 1% equity.

Given your status (recent graduate) and company's status (pre-seed), option A wouldn't be ideal for both the parties but less so to the company. You can use that as a negotiating strategy to get to option B which would be best for both.

Also, keep in mind, the CTO has built the platform for 2 years so she might also have some background in architecture. If true, your negotiating position is less strong.

You are in the best position to know how the business is doing or going to do in the next couple of years. I would adjust the numbers depending on the risk in the business.

Finally, if there are too many unknowns on the business side, then I would only stick to option A. It's a personal decision but my risk appetite as an employee is very low.

I'd recommend sticking to POST requests with body that fetches the data you need. I know it's semantically odd because the POST request not creating a "resource" on the server. But it's practically very useful as it'll work well with client libraries, load balancers etc.

You can get some inspiration from GraphQL for your use case. All GraphQL queries are POST requests with body specifying what data the client needs.

> and is still fairly unpolished (but very promising!).

I'm all ears. Please write to me at amit@reviewnb.com

I built ReviewNB and push improvements almost every single day :)

I am the developer behind ReviewNB.

> I just wish it could live within Github

Whenever I thought of integrating the review experience in the GitHub UI (via browser extension), I always thought of overwriting the GitHub diff UI. That approach is very hacky and would result in the extension stability issues (any DOM change in GitHub diff could break the extension).

But I just looked at Zenhub and having a separate tab for notebook review could actually work! Since it relies only on the tab related HTML, the extension would be relatively stable. There's still a question of how to post comments etc. But it might be a good start to just offer notebook diff in a separate GitHub tab for pull requests.

Thanks @the_watcher.

Jekyll with Netlify.

> hard to review code

I built ReviewNB specifically for Jupyter notebook code reviews [1]

> various kinds of tests for each of them

Checkout treon, open source test framework for Jupyter Notebooks [2]

Some other tips,

- Move code into Python modules whenever possible

- Maintain dockerfile / requirements.txt so your notebooks are easily reproducible

- Setup treon in a CI/CD pipeline

- Setup internal Binder [3] for quickly launching notebooks on cloud machines

[1] https://reviewnb.com

[2] https://github.com/reviewnb/treon

[3] https://gke.mybinder.org/

I worked at Amazon for 4 years before starting my own solo bootstrapped venture.

- 6 months is very short time. Carve out 18 to 24 months for a real shot at monetization

- Consider moving to a low cost place or even back to your parents house for a year or two

- Plan finances in a way that you won't regret spending couple of years on a project that produced $0

- At $2k burn, 2 years of free time to pursue your goals for $50k should be a good deal in your position. If not comfortable, wait it out another year or two at a high paying job. Release 1-2 very small products in that time to understand how this world works.

Can someone attest to accuracy of PMS5003?

P.S - These are pretty cheap on AliExpress - http://bit.ly/2XoW0is

Make programming accessible to scientists.

Today, running any compute/memory intensive experiment requires working through so many tools and terminologies (e.g. AWS, SSH, python, dependencies, virtualenvs). Scientists really need just Jupyter notebook like experience that's collaborative, reproducible, and powerful (i.e. run on any hardware with 1 click).

Just checked out live commenting feature on Observable [1], the ability to send code suggestions and preview + merge suggestion with 1-click looks amazing.

I built a tool [2] for Jupyter notebook code reviews which has commenting feature for GitHub pull requests (regular text comments). It would be great to have actual code edits/suggestions as review comments.

[1] https://observablehq.com/@observablehq/suggestions-and-comme...

[2] https://www.reviewnb.com/

> That is an architectural failure.

Let's not jump the guns too soon. Analytic products are notoriously hard from scaling perspective. UI, APIs, Infra that works crisply for 1x data, starts to become sluggish at 10x and really breaks down at 100x.

Startups solve the 100x scale problem when they get there (sensibly so). In this case, they got there way too quickly thanks to HN traffic.

> they decide to build their own closed-source platform

How does it matter that the donation platform is closed-source? Open market principles still apply. People will (and should) use it as long as it's easy, efficient, cheap to donate to whoever you wish to donate. If the platform misuses their dominance, people will figure out and alternatives will emerge/thrive. Until then, why complicate things? Donation is not like a lock-in into some closed source technology.

To summarize,

- OSS contributors on GitHub can apply to become "sponsored developer" to accept donations

- Developer sets monthly sponsorship tiers (amounts & benefits)

- GitHub will match upto $5k in donation in Developer's first year (1:1 match)

- GitHub will not charge any fees in the first year

- In the future, they may charge a nominal processing fee

- Currently only individuals can donate to individuals, org/team support (on both sides) to come soon

I am a solo bootstrapped founder (like yourself) and RescueTime consistently shows 45 to 50 hours per week.

I strongly believe WHAT I do in those ~50 hours is much much more important than squeezing in another 10-20 hours per week.

You bet. I built ReviewNB[1] specifically for Jupyter Notebook code reviews.

There's also,

- nbstripout[2] for stripping outputs automatically before every commit

- nbdime[3] for diff'ing notebooks locally

- jupytext[4] for converting notebooks to markdown and vice-a-versa

[1] https://www.reviewnb.com/

[2] https://github.com/kynan/nbstripout

[3] https://github.com/jupyter/nbdime

[4] https://github.com/mwouts/jupytext

Access to all/some contributor's local git repository is a powerful capability but you need to think deeply about 1 or 2 core use cases. "Pull up a chair" is only a surface activity, what's the user's real intent here? Is she trying to understand some part of the codebase or pair programming or debugging together? How can CoDiff help in that core activity?

To get you started here's something I would find useful,

- If I am starting to edit parts of the code that would create conflict with remote or peer's local state, just send us a notification. Much easier to avoid merge conflicts than resolving them.

Also think of developer psychology, e.g. I don't want peers to randomly peek into my WIP code. Things of that sort. Good luck!

Nice work! Do consider slapping a simple UI and hosting it somewhere online. You'll be surprised how many organic visits it'll get a year or two from now.

Bonus points if the website copy overlaps well with search keywords :)

> this generalist thing is utter nonsense

By your own description, you sound like a generalist with ability to dive deep into the areas needed. You seem to refute the core premise of the article but your description says otherwise.

Converting notebooks to markdown is a fine idea (although you have to maintain both versions).

I built ReviewNB (https://www.reviewnb.com/) specifically to review Jupyter Notebooks on GitHub.

Why write emotionally charged letter instead of one backed with facts? Amazon is claiming [1][2] that Elastic has been intentionally unclear about what part of Elastic stack is open source vs proprietary. It would best serve Elastic if they respond to that with facts.

If the claims are true, and done intentionally, it's a really bad move on part of Elastic. The ambiguity around licensing hurts all their users and not just Amazon.

[1] "Unfortunately, since June 2018, we have witnessed significant intermingling of proprietary code into the code base. While an Apache 2.0 licensed download is still available, there is an extreme lack of clarity as to what customers who care about open source are getting and what they can depend on. For example, neither release notes nor documentation make it clear what is open source and what is proprietary."

[2] "Individual code commits also increasingly contain both open source and proprietary code, making it very difficult for developers who want to only work on open source to contribute and participate"

I built ReviewNB [1] to see visual diff for Jupyter Notebook changes & do a code review on it (by writing comments on cell changes etc.).

One of the next feature for ReviewNB is a CI pipeline for Jupyter Notebooks on GitHub. The idea is to make it easy for users to specify notebook "tests"/"checks" that can then be run on every change.

Given the nature of Notebooks, it's a bit hard to design CI for it in a clean way, but I appreciate any inputs or use cases that you might want to see fulfilled.

[1] https://www.reviewnb.com/

If you focus on increasing engineering quality, retention will follow.

> there's still an astounding number of bug reports for a simple app.

Why don't you reverse engineer some of these bugs and see how & when they were introduced. What step in your development workflow should have caught those?

> The development process is indeed slow and full of fail-safes

I have seen engineers who focus on less meaty stuff in code reviews (language semantics, coding conventions, naming etc) and miss out on system design, regression, logical mistakes etc. Former takes less mental effort & is limited in it's usability while latter takes time/energy but is worth the price. See if this is happening in your organisation.

> how they actively engage in bickering and in-fighting between their own teams

My guess is some of your engineers are less focused on product/features/customers and more on the stack/technology/tools they are using. I don't know how to change this (lead by example maybe?).

Very few people donate because they feel benevolent. Most Patreon type donations come because companies either want to sponsor further development or need a maintainer for the critical OSS components in their stack or both.

If you are only looking for couple of hundred $ per month then you can probably still find it via benevolent donations. But if you're serious and want to spend more time on the project then move to freemium model. See RescueTime for motivation.

Best is to keep all existing features as free and think of one solid new feature you could build that can be sold as premium. In your case that could be "sync reading progress across devices". If I'm super user of Polar, I would want to access progress on my phone and get some reading done while commuting. Just saying.

Lastly, if you only convert 5% of current users to premium then it's 100 paying users right out of the gate. Not a bad start eh. So stop relying on donations & think of capturing the value you are creating.

- Never aimlessly browse through large codebase. Pick a change you want to introduce, maybe a string change, a small bugfix, low hanging feature etc. Goal gives you the motivation to keep digging through things and in that process you make a good mental model of the codebase.

- Sprinkle logging statements all over the place and tail logs to figure out the execution flow.

- Look at the past merge requests. They typically have descriptions. Go through the ones where you have some context about the goal of MR.

> A given feature/bugfix/whatever is gonna take as long as its gonna take.

If this is every developers attitude how can the team make any plans about product roadmap? How would the team decide what to take on in a week/month/quarter?

I'm a developer and I understand difficulties in estimating. I also know of poor leaders who use estimation trap to guilt developers into an impossible deadline. But this attitude is not helpful and will not fly in any good team. If you apply yourself to it consistently, estimation (with certain degree of error) is not impossible. I wrote practical tips somewhere else in this thread.

Earlier this year, I wrote these tips to improve estimation: https://blog.amirathi.com/2018/02/05/science-of-software-est...

I will summarize it here:

- It's not just about code. New developers typically don't account time for testing, documentation, data migrations, backwards compatibility work and such

- Spend a few hours to discover unknowns. Unknown unknowns can rattle the estimation big time whereas known unknowns can be factored into estimation with some upfront research.

- Have a deeper conversation with product owners. Often you realize that some nice to have use case is taking 80% of the time and can be decoupled from the core feature. Win-Win.

I disagree. At Amazon, I never saw anything free in the break room except drip coffee. Stock has soared 6 times in 6 years.

At a startup, we always had free lunches every day (virtually anything you want) despite up and downs in the business.

Version control for Jupyter notebooks was one of the biggest complaint I had. Specifically, diff and merge with the JSON files (.ipynb) is ugly.

I built ReviewNb[1] to solve one of those problems (diff). Note that, there is nbdime[2] which works well for local diff/merge. The idea for ReviewNb is to have much tighter integration with GitHub etc.

[1] https://reviewnb.com

[2] https://nbdime.readthedocs.io/en/latest/