It could absolutely be storage limitation. Just because converting it to a doc is a solution doesn’t mean it’s not storage related.
More than likely, note content and doc content are stored in 2 completely separate DBs, probably built by different teams that know nothing about each other apart from the API to convert a note to a doc.
Assuming they are stored in different places, different DBs have different storage limits. Chances are if notes are intended to be written and referenced quickly, they may have used some kind of key-value store for fast retrieval, but the storage limit will be smaller than of you were storing it as a file in S3 or something like that.

Or it could of course be something else entirely. Could be some product manager snorted some coke and decided people should never have notes longer than 50k chars because reasons. Or “but people need to have a reason to use Docs over Notes otherwise why have both”.

The Software Engineering StackExchange is one of the most useless places I’ve ever visited. It’s as if virtually no kind of question is allowed.

@jestdotty Not sure what diversity has got to do with it?

It may be acceptable to grab an AI generated snippet of code if we aren’t sure of the best way to implement a particular thing.
However, we should still be writing the tests that verify its behaviour.
I think that might be something that people are missing in the AI discussion. Just because you didn’t write the code doesn’t take away your responsibility to provide regression tests. And that extends to security/performance review as well.

This one

My guy if you are waiting that long for 15% coverage you might as well delete them

@Root Joke’s on you it’s a DynamoDB table. Checkmate hackers. Oh wait, now you know…

@Lensflare Entered manually to a GraphQL mutation

@Demolishun It is absolutely a veiled “didn’t sanitize inputs” problem.
They are not passwords or articles or any kind of freeform content, they are IDs which will later be queried against.

“Because we are so small, we work in silos”

Being silo’d isn’t a symptom of having a small team, it’s a symptom of having too many different projects to work on at once.

none

I mean, to an extent you can’t really complain. You stated up front there might be bugs, and yet you still said yes when they latched onto the first bug and asked if you could resolve it.

@Lensflare probably more like ServiceManagementService

tacking “Service” on the end of every class name.

PayCalculationService
ReportGenerationService
PipelineExecutionService

Things that have perfectly good verbs in them but we ignore those and just add Service because everything has to be a service these days.

Im a senior with 2 interns on my team. One of them tends to just ask without trying first and needs hand-held a lot. The other tends to waste a lot of time trying to figure something out that isnt even a technical issue but something related to the project itself that they would never figure out on their own anyway.
I wish they could both meet in the middle somewhere.

I almost want to apply and interview just so I can reject them and waste their time

@EmberQuill Pearson’s spyware does use webcam and mic with a proctor on the other end who watches you throughout the test. You also have to submit photos of your workspace from various angles to show you have no extra devices/displays.
I was even told to stop covering my mouth during my first AWS cert (I was leaning on my hand while thinking).

lul. Its been about 5 years since I did iOS dev now. Good to know nothing has changed.

@ultrageoff Honestly for that use case I would definitely consider AWS, but try to only use serverless options where possible like API Gateway, Lambda, DynamoDB etc.

For small apps with very few users it can end up being effectively free since you are charged based on API usage. And some only start charging when you get into the realms of millions of requests per month.

Circuit breakers in Resilience4J

You also need to install this bullshit if you want to take an AWS certification exam remotely.

And the software runs like trash. I did the solutions architect cert recently and the exam literally crashed halfway through and Pearson tech support had to call me to restart the program.

@justDeployIt I did actually.

Work at a better company that values my hard work.

I still have it 9 years later

Engineer Man, NetworkChuck and John Hammond are my top 3 channels for tech stuff atm.

@jespersh much obliged. I remembered this scene last night and my nerd brain went “wait isnt that basically DHCP in a nutshell” and this dumbass meme was born

10,000% this.

Other things that deserve a slap:

- using story points to represent days (but still using fibonacci like a retard)

- nitpicking every story in sprint retro asking devs to explain why a ticket took 6 days instead of 5

- just generally using story points as any kind of performance indicator whatsoever

@lastNick If the team is constantly fighting fires, fixing bugs and rarely meeting deadlines, something (probably a lot of things) is being done wrong.

The most important thing IMO is trust. The team needs to be trusted and given the flexibility to do what they need to do. Too often the team’s work is mandated by what the management think should be done next but really that should be a joint decision with technical input. And managers need to trust that the engineers know their stuff and can get the job done.

Trust = absolutely necessary
Key Performance Indicators = evil

Thats my formula for software development lol

I worked in a team once that enforced this. While it is true that it can sometimes be done for billing/tax purposes, in my experience it was done to compare the estimated time of the ticket against the actual time spent on it. Then management could grill devs for going over time. Also for making sure we basically werent spending any time on anything not directly related to sprint tasks.

It was used as a means to monitor us and blame us for work not being finished at the end of the sprint. It had no other benefit.

I work on a team now that does none of this. We dont have to log all our time and we dont have to fill in timesheets. And we are much more productive than that other team can ever hope to be.

I think its toxic at best. It implies that you should be spending every minute of every day working on tickets. It leaves no room for personal growth or even just feeling a bit burned out one day. Also tracking how much time a ticket takes is a waste of time and another toxic practice IMO.

This isn’t an advertising platform. We aren’t your target audience.