How we used design patterns and springboot's capabilities to power a critical dashboard for our flagship application!
435 karma · joined June 2, 2021
Remote: yes
Willing to relocate: no
Technologies: Java, Python, SQL (Postgres), Springboot
CV: https://github.com/bruno-oliveira/quality-software/blob/main...
Email: olivbruno8@gmail.com
Have around 6 yoe as a developer. Looking for what's available in the market, interested in transition to senior developer.
An important point: don't see it as a "should I consider it or stay a BE developer?" kind of thing. If you accept the PM role, even if it means more money, the skill sets and responsibilities will be completely different so be aware of that too.
I ended up empathizing more peraphs because I have experienced some level of loss in my life both from family members and friends when I was very very young, and I feel that reading a text line this one many decades later probably triggered something in my subconscious in that I could probably understand how this dad was feeling in a way that I could not comprehend when I experienced those aforementioned losses when I was much younger.
I'm not claiming to understand his exact situation, I'm not married, I don't have kids and it's not something you can project or relativize in any way, we're on the same page there.
I just meant that understanding part of the feelings of grief and the innocent way that Lilly near the end of the article says she'd search every cloud just moved me in a way that I also found unexpected myself, that's all. I know I'm not special and I don't want to be or claim to be, because I know everybody will experience loss, but, simultaneously, this just hit me more than I expected it would which is what moved me to write the above comment, it was truly sincere.
I see a lot of people being so very happy in the comments, and, well, I've tried to think long and hard about how to apply it to my current domain but was a bit at a loss... Maybe some practical examples can help?
Once it's public and gains "customers" the responsibility grows a bit, otherwise don't post it at all publicly, after all, if you're not going to care about real world use cases, it's just as valuable as any toy project that hasn't seen the light of day.
This type of almost "passive gatekeeping" is the reason why we've formed several OSS projects we rely on. Yes, we incur maintenance burden but the predictibility gained is Invaluable.
Unless you are a very important client who is paying money to the maintainers or unless the project is OSS but let's say, backed by/open sourced by a company like Google (as in, not some unknown person who kind of answers to no one) the chances of meaningful contributions landing are effectively zero.
If you are a client of a given library working for "Unknown company 8965688" and you are using a library and make a PR with a change you need or request it, in my experience, you'll simply be ignored.
Then comes the original post: we'll fork the library to an internal repository, make it our own, and stop depending on the whims of the maintainers who care absolutely nothing for the people who request features precisely _because they are actively using the library_ and need an improvement.
OSS has become a really, really bad place to be when it comes to actively depend on something that is managed by someone who simply doesn't care about you in the slightest.
Then, as we have people competent enough in the technology, forking becomes the natural thing to do.
What the comment above me meant is that probably this is a shared feeling by many other people because the initial hype (like all the blog posts etc) died quite fast once it went paid.
I can't imagine how much it cost to train the thing but oh well, I guess it's irrelevant for me for now since I won't be using it...
I loved it for some scaffolding, quick drafts or explore some language features, but, not enough to pay monthly for it (yet!)
Interviewing? Sure. Those LeetCode algorithmic problems have a tendency to sometimes touch upon these well-established values of the underlying architecture of bytes/bits and how memory pages are structured, etc.
The thing is: Working with Java and Python in your classical corporate job maintaining a DB schema, creating and/or optimizing endpoints with Flask and/or Springboot, most of these underlying concepts will be shielded from you entirely.
Again, in Java, you can specify the load factor for a HashMap when you create it... I bet you 99% of the developers working with Java have never needed to do it or might not even know what it is or how it works under the hood.
Maybe they don't even know that internally the hashtable size is managed in powers of two... but again, I don't truly believe this matters for 99% of the work you'll be doing.
It's either something that you need to use or fully understand, or something that will always be abstracted away from you.
8 or 2^8 or 2^8-1 are just numbers basically.... It's good to know a bit their intrinsic meaning or why they are relevant just as a general knowledge, but, unless you are doing C programming at a very low level, embedded systems, microcontrollers, etc, this is just knowledge that will _never_ be used.
But... does it matter?
Unless you are working with hardware or in embedded systems more directly, it ABSOLUTELY does not matter at all.
What matters is to have a critical eye for numbers when they matter and/or are "off". That is much more valuable for the day-to-day work.
"Damn, before we could easily hit this endpoint X times per second and after that refactor and library change it's down to X/5? We need to have a look".
Sizes of DB tables, latency of endpoints and being able to properly read stacktraces or logs from a third-party service is much more valuable.
PS: people writing in the comments about not knowing how text encoding works, about sending data trough sockets, etc... Folks, you know how to do these things because they are required from you at your day job, you probably had exposure to proper patterns and got help from experienced people within that particular niche at your company. That's all. Knowing 1 byte is 8 bits is absolutely meaningless knowledge on its own.
I needed to know these "standard sizes" for my CS degreee,sure. Do they matter for my day-to-day work? Not in the slightest.
I think it's only at the real low-level or hardware/assembly or, for instance, a bit above the stack, say, optimizing a data model or fine-tuning a DB engine for a given domain, that the old timers would really shine.
I see it in my daily life: my dad was a Fortran programmer way before I was born, so, maybe you know... 1970s or something like that. He was actually very good at his job, getting a research position doing some serious programming work that was seen as groundbreaking at the time, doing some finite element modeling on extremely resource constrained environments, probably what we would call data-oriented programming today, but taken to its extreme....
However, he didn't really keep up with programming after a few years, shifting to MATLAB based tasks for some university courses he lectures... and I feel that the complexity of today is just too much for him to grasp as it was. It's just too many moving parts and too many layers of abstraction to sift through.
By the same account, I expect your typical developer of a regular company, myself included, seniors included, etc, etc, to be completely lost if they had to optimize code for a given hardware and needed to write some assembly, or whatever, disassemble some JVM class files, etc.
In Europe, these problems still exist, certainly, but, it's a lot easier to find places/companies that can be deemed as healthy, or let's put it like this, that aren't making the news headlines.
I would propose that you do your due diligence and investigate the business, company, maybe even some of the C-Level people... It can be perfect or terrible, it just depends on each and every individual case.
About the offers themselves: Double the current salary feels a bit too good to be true, so, if a large part of this salary is paid out in equity/stocks, this can tie to the point above about evaluating the health/runaway of the company and how it's been doing over the last few months at least.
I get it, interviewing sucks, Leetcode sucks and FAANG-level interviews are tailored for a very specific skillset.
And while Leetcode problems are a horrible proxy, there are a few caveats to be aware of:
- In terms of acquired skill level, I guess we all agree it's harder to gain context on a new codebase and debug production issues at 6am. However, we do this repeatedly, every time we switch jobs. Contexts are different, business, issues and tech stacks are different. Yet, we always succeed. Leetcode should be the same: just a crap you have to shove down for a few months before interviewing and then forget about. It's not pleasant, but, if you can debug prod issues with ease, a few relaxed months doing some closed-form problems that repeat themselves over and over should be _doable_.
- Not all companies require technical interviews based on Leetcode.
In the end, the weight of: effort put in vs. company reputation vs. salary will end up dictating what you will be able to (or want to) apply for and work hard for.
I personally am on your boat: hate leetcode, suck at it 100%, but, I've accepted that there are many, many great companies which have fair and representative interview processes and still allow you to do meaningful work. You know, the companies you've never heard about on the internet in your local area or city? Yep, those ones.
I believe that this kind of "self-pity" or claiming that the entire industry sucks, is broken, needs Leetcode is a bit too much. Sure, some very high stakes companies do it, but, again, those will attract the engineers who have the willingness, perseverance and skill to power through those problems (plus system design too!!) and get the job. It's a skill. The more conscious effort you put into it, the better you will become.
The real issue is then losing sight of the forest for the trees: the real work begins once you are hired. I don't know if this process truly finds _better_ candidates in average... But, imo, it doesn't need to: there will be extremely smart people who will simply stay away out of these types of processes and that's totally fine, as it keeps the talent pools balanced and creates super cool and interesting work environments and projects centered around "the other 99%" of companies.
Unfortunately, not all that glitters is gold. It feels extremely beginner oriented, only touched basic concepts taught at uni level and it shows a huge disconnect between the theory and the real world work of a developer leveraging data in any way, shape or form.
Don't buy the book, it's so not worth it.
It's not a true knowledge sharing platform, it's just a popularity platform where being the first to write about the new ANGULAR version 9999 is seen as a sign of great wisdom and being "on top of your game as a dev".
I wrote there a lot and stopped exactly due to the misalignment between what I wanted to consume and write about.
More generally, I find that ad-hoc aggregator websites like HN have a much higher hit ratio with my own interests. Also, if you're a professional developer actively involved in open-source and working within the JS/TS ecosystem you'll likely get a bit more value out of dev.to than I did, I guess it's just not my style...