brunooliv

How to install it on the phone?

I absolutely agree with the overall sentiment and I relate very strongly with all the points, except that 2 weeks isn't the norm at all in scrum or agile... It's not standardized as such or made official anywhere so maybe if you made your sprints, say, an arbitrary number > 2,like 5,would things be better then?

Just subscribed, this is really awesome!!

Carbonara - In most European countries/capital cities that are not in/or Italy, all the restaurants I've seen add cream to it which honestly makes the dish even heavier than what it already is, charge quite a lot for a plate, and, in 99% of the cases, you get a subpar, lukewarm pasta dish.

At home, it's very easy to do it well, following the original recipe, it's extremely basic, very few ingredients, and honestly, tastes really awesome!!

Disclaimer: I'm portuguese and a total foodie and pasta dishes are right up my alley, so, YMMV.

It's satire, calm down y'all!

Took me too many comments to reach the obvious one. I guess some people take things too seriously :')

Really nice read! I first heard about Hexagonal Architecture thanks to the posts of a cool developer I used to stumble upon in Quora frequently, but, since then, I've seen it mentioned in a few more occasions and it's nice to see it in action in Netflix!

Slightly unrelated, but, this is also mentioned in the book "Grokking functional programming" from Manning, essentially keep the stateful pieces of your system at the boundaries and strive to keep services which handle business logic as pure and side effects free as possible.

"Talk is cheap, show me the code." Any engineer worth their salt will "naturally" communicate by asking questions, appear friendly, or even admit when they're stuck or don't know something.

The problem is the reverse is probably as common, but, honestly, equally valuable: if you have a person who simply shows amazing tech skills, and talks when prompted to, I mean, will you reject this person in favour of a less stronger candidate just because that weaker candidate was more outgoing?

I mean, in technical interviews you have to be technical and solve your stuff, that's it.

FAANG system design interviews actually somehow require some clarifying questions to clear out ambiguous requirements or probe for missing data, but, I have seen and witnessed people immediately tabling X, Y and Z assumptions and go "assuming these....." and immediately craft a perfect solution - pass with flying colors.

The rest will be gauged in behavioral interviews and in the final decision meeting to put forward an offer or not.

But in technical interviews? Just solve the thing.

How are rates for small apps? I've read the pricing table in the website and it seems pretty generous, so, for a small poc style app, is this limit enough?

Kudos to you for "learning in public" by showcasing part of your learnings online!!! I think this is extremely important to do!

Not everyone is an innate rockstar developer who provisions k8s clusters for breakfasts and delivers features for lunch!

Being a developer is a really hard job and there are endless complexities and difficulties along the way and when we are more seasoned already.

Don't let any negative feedback deter you from keeping doing what you're doing: learning from your mistakes and improving along the way!

So... essentially you have to go around hoops in the way you communicate internally? LEL.

Digital Ocean works pretty smoothly

I liked this post so much that I wrote a short blog post inspired by it: https://medium.com/@olivbruno8/improving-as-a-junior-swe-322...

Posts like these are the reason why HN is invaluable as a resource for engineers at any career level. There are always given gems like this that you can feel the experience coming through the words. This is an amazing post!!

This is probably a good list. Some points I don't agree with, but, as a person who kind of invested in the book by buying it while it was in MEAP at Manning, having high expectations for it, I can say I was extremely disappointed with the content. I found some passages unclear at times and the whole idea of mapping the data oriented programming approach taken from functional programming to a general purpose way of designing programs and using JS to convey the message, somehow didn't make it click for me.

It's a good list of tips and I hope the book was successful and helped people!

"The Goal: A process of ongoing improvement" by Eliyahu M. Goldratt

An amazing introduction to the theory of constraints and the value in doing things in small, incremental improvements

"A universe from nothing" was also amazing!

This is a really great point!! It's not only about knowing facts, it's also a bit more meta and it's knowing what to know and what's worth jolting down somewhere

Glad to see this has ressonated with so many of you!! Thanks for all the amazing insights in the comments where, as always, a lot of the value lies.

Thanks for the warning :)

In my limited experience, this is rarely so simple as to being able to push back on a technical decision when the reality will feel like pushing a square through a circle peg. I mean, as rightfully pointed out, if the reasons are more political than technical, pushing back can have nefarious consequences for the people involved. Doing our jobs as engineers is about raising the alarms when needed, but, if all you get is resistance back... Assuming it's not your product, not your company and your ties to the thing are mostly technical... Then if advocate for the "not your problem" attitude and you can simply be content to let it crash and burn and show up the next day with a mop to fix it.

Dealing with incompetent management is never nice or easy, but I'd advocate that as software developers, we're quite privileged because we get paid pretty well, work is versioned in source control and most messes are physically unseen, and cleaning up is "usually" not a big deal.

Yes, been trying to do just that, thx!

You're absolutely right, thx! Consistency is def there in my case, just gotta try and make it interesting :D thanks a lot!

Thx! yeah I think mostly I want to see what kind of engagement I can get with my content mostly to have an idea of the cumulative reach of sharing on linkedin and here every once in a while, I mean 10 or 20 weekly views or wtv and I'd deem it a pretty good success, especially because I write mostly for myself, just curious to see the engagement.

Thanks! I do have been posting some content frequently here ahah, but thanks! I'll try to setup a Google analytics stream perhaps to see if I can get more insights! Thx!

hey this is super good, might even attempt to put together a short blog post with this as the central idea! thanks!

Great stuff!!

I've written my first book: Geared towards anyone who wants to learn Flask, Python and good coding practices all while developing an app to be deployed on Heroku!

pigeonhole principle not strong with this one...

I've kickstarted a docs centralization initiative at my current work, precisely because of all the issues you described. We have it in version control. There's a top level repo folder called: documentation and inside there are dedicated subfolders for things like onboarding, testing, domain specific tips/knowledge, etc.

A huge advantage of this approach is that the docs are close to the source and in the most logical place for the relevant stakeholders to benefit from them. This has worked quite well!

Python for job orchestration (Airflow) and data science (numpy, scipy, etc) , Java 16+ for the general enterprise, product development, Julia for HPC. C for embedded, C++ for games, highly intensive systems.