I remember when I was a junior, I was a programmer for a survey website startup. They wanted the flow to be dynamic depending on previous answers. They apparently didn’t know what MVP was because the „genius” architect invented his own language that was a retarded combination of Basic and Excel formulas. I remember writing a parser, interpreter and even something like gc.
Of course the company is dead know.

scrum is fine for clients who don’t know what they want and for a team of nonexperienced, badly motivated developers. But for the seniors, the storypoints, sprints, demos and retros are nonsense, and as OP said, often it’s just a micromanagement in disguise.

When there’s a technical work to be done, the standard practice[*] in scrum is to hide the work inside some „story” task, to prevent the micromanager from cancelling it - „hurr durr, log aggregation is not business value, we will think about it after going live”.

[*] I’ve seen this in every project that claimed to be agile.

Cassandra is designed to be good at write heavy. Trying to minimize the number of writes is usually a mistake: https://datastax.com/blog/2015/...

You won’t find older people in cool startups, because they have been there and they can see the BS. Organizing your company as a cult (aka „startup culture”) is just a trick to pay specialists way below the market rate for overtime work.

Actually, it makes life a little harder. The „master” convention is well established. Many tools assume it. A lot of blog posts are now outdated. People learning git for the first time will have to keep this rename in mind. There will be people who accidentally push to master out of habit.

I seriously think that „Bad Blood” is one of the best books I read last year. This is beacause that shit IS REAL. Every startup ever.
Thanls for an advice about fighting the imposter sindrome.

- Because you don’t know how your communication format will evolve and what you will do with the data you collect. Stick with a solution that works.
- 2 years from now, some poor junior will have to maintain this piece of crap. Are you sure he is capable of not fucking up parsing and escaping?

Do the least valuable people stay in the office?

That would be a genius/evil HR policy in face of the incoming slowdown.

DO NOT WORK WHEN YOUR PAYMENT IS MISSING.

With this kind of bs, I wouldn’t trust a single word they say.

Think of it this way: They have already answered your question about the pay increase. You just don’t like the answer.

When you approach your boss about a pay rise, everyone knows what game is being played. It doesn’t matter if they have time for a meeting. You are now a resource in a high risk of being lost. Yet, they are accepting that risk.

Good luck job hunting!

You will be surprised in how fast a meeting will be scheduled once you give in your notice :)

But where do you draw the line between YAGNI and overengineering?

There’s 99.9% chance that the startup, I’m working for, will never have more than 10 concurrent users.

I can implement everything the laziest way possible and keep collecting the salary until we run out of the runway.
Or I can at least pretend to design something for thousands of users.

What do you expect from a platform where people wear ties in profile photos?
When someone posts stupid inspirational quote on FB, at least someone might respond with „that’s BS”. This doesn’t happen on LinkedIn. Everyone keeps their „professional attitude” not to scare the recruiters.

For example, my former company has recently bragged about the fact that they planted a tree. A single (one, 1) tree. That’s so much BS given how much the executives fly for useless meetings and in what industry they operate. However, I don’t call them out. I’m a proffesional.

Not sure what you are trying to achieve. If users should not be able to guess the next number, so that they cannot steal a code from another person, then seeding with the current epoch milli is almost the worst possible idea.

If I know the aproximate minute when my victim executed a transaction then I only need to check 60000 combinations.

If you need to use a random token with less than secure number of bits (for storing in a human brain or in a qr code) then make the tokens random, but enforce short lifetime.

Hey, I didn’t say to move old projects to Kotlin.

Lombok is fantastic. Total agreement here.

I think your hypothetical boss of a new JVM project overestimates the cost of converting a Java dev into a Kotlin dev. This is not like a conversion to Scala or Closure.

The fact that Lombok(a compiler hack-plugin) exists and is the norm says a lot about Java.
If you want to get rid of boilerplate, why don’t you write in Kotlin? You can keep the Java OO style and your favorite libraries.

2000$? That is a rookie number. I’ve seen an entire office gathering in a rented hall to meet new hires who’d just flown from another continent for this. Their job was unrelated to the office.
Basically, they could have sent an e-mail, saying „Hi, I’ll be your new vicechief of whatever. You probably won’t interact with me at all”.

Pretty useless technology. It works only in environments with low trust and no regulations. If you are a businessman in Ethiopia trying to sign a deal with someone in Venezuela, maybe a blockchain technology can help you, but you are still depending on the computing power of the rest of the world.

In advanced countries, companies are paranoid about protecting and controling their data. Good luck trying to convince them to put everything into a public database powered by Chinese hardware.

In theory, someone should track progress and everyone should seek synchronization, so, in theory, daily meeting are a cargo cult. In practice, managers are lazy and programmers don’t communicate, so it’s better that the tradition exists.

„Our entire team are senior devs”
That’s an orange flag to me.

Without a healthy fraction of juniors, your codebase becomes gradually convoluted. They whine and complain and at least indicate possible overengineering problems. Best code review from a junior, I received, was „I don’t understand this”.

The seniors adapt too easily to their own BS.

This year, in Poland, the government decided that it can’t be bothered with collecting a fee for owning a TV set. They just gave 500M$ directly from budget to the state TV station. They don’t even try to hide the fact that the programm is a single party propaganda.
So much for protesting by not owning a TV.

The book you want to read depends on your role. I don’t think mobile developers would care about „Continuous Delivery” by Humble&Farley, but it’s a good read for DevOps/backend.
A good career advices can be found in „Beeing Geek” by Michael Loop.

Yeah, back down.

This is not your business and not your responsibility. If your company has a role called „chief architect” or similar, he is the one who should evaluate the processes. Hiring cheap offshore devs is a valid business decission. They just don’t tell the onshore devs all the reasoning.

You are a junior software dev. Your skills are in writing software. You have spent years in training for that role. Don’t think for a second that it also means you are good in power games. Actually, it means the opposite. You invested your time in learning computers, so naturally, you lack a lot of skills in dealing with people.

You don’t have a slight chance in fighting an experienced manager. The fact that the snake hates you means that you have already shown your cards. Noob.

Besides, what’s in it for you?

You are a junior, so your priorities should be:
- collect just enough salary
- gain experience for your resume
- earn positive reputation
- jump ship

Let me become a devil’s advocate for a moment...

Was this guy actually given a meaningfull tasks or training on his first day? You seem to be surprised by him joining, so there was a failure of communication in the company. Probably not the first one.

This happened to me so often, that I see a pattern: when a team is not thrilled about a new member, they tend to ignore him and this makes him lose confidence, start slacking off, generally not leaving a great impression. In good teams, there’s a plan and a dedicated mentor who is responsible for the onboarding.

Wat.

Python is closer to Javascript than to Kotlin or Java.

This reminds me the Chinese who displayed panda porn to pandas to increase their libido. It worked.

@12bitfloat
„Are they breaking compatibility on each minor release?”

Yes.
I’m not sure if that’s a language problem or the ecosystem, but the topic of compatibility is a horror in Python.
And you cannot escape it by saying „fuck this Python crap, I’ll write my scripts in bash”, because many tools depend on it. For example, AWS cli is written in Python.

Why?

Predicting human behaviour is either futile or trivial.

If you are looking into real time estimations (not predictions) and if you are considering larger „places”, you need to contact mobile network providers.

Currently: 40kloc - 9minutes for all tests (sequential run). 85% unit tests coverage.

In previous job: 1Mloc(horrible Java/Hibernate/JSF monolith): 6hours, the tests were never green, 60% unit tests coverage.

This idea is an illusion. The real complexicity of business systems lies in the business rules themselves, not in the glue code.

Sure, you can save a few days with ready-to-use templates, but they will be obsolete in 2 years after going live and will require rebranding or modifications. If you let -idiots- non programmers design software systems, you will end up with unmaintainable, untested mess with even less documentation than you would get from real developers.

The worst software nightmares I saw were based on this idea of a platform designed to be friendly for non programmers. The systems were so convoluted that only senior developers could create a mental model of what was going on.

Also, google „Inner Platform Effect”.

Once someone asked me what SOLID stands for. I screwed up the D - it’s apparently not Don’t Repeat Yourself. The hiring architect wasn’t happy.

To this day I don’t understand this fascination of SOLID during recruitement. You show that your code is clean by writing it, not by recitation of formulas. Workplace is not Sunday school ffs.

BTW:

S is impossible to define and therefore useless.
O is obsolete.
L describes rules for code that should not be written in the first place.
I is fundamentalism
D (dependency inversion principle) is OK, but totally obvious.