mobjack's comments

It is understanding that leadership doesn't care about the technical details. Devs are expected to figure out these details on their own.

Instead try to understand what others really care about and frame the discussions around that.

I am a big fan of the Agile Manifesto, but Agile has evolved to be something completely different.

It became a rigid process where people debate the definition of story points rather than getting shit done.

A production replica if you want to be safe

You ask someone in slack. If that isn't sufficient, set up a small 1 on 1 meeting to discuss.

You can't avoid all meetings, but you can keep them few and small.

Because the senior dev always says no.

At my startup, every new management hire thinks they can improve our process by introducing scrum.

Every year we make another attempt at it only to find out that it isn't agile enough to keep up with the pace of the business.

Computer science is one of the harder subjects to assess knowledge through tests.

In other industries, passing an accreditation exam gives you value in the market. In software engineering, certificates are seen as useless.

This can explain the cynical attitude programmers have against testing.

There comes a point where impossible to leave code in a better state without a major refactor.

The choice is between writing a few ugly if statements making the code a little worse or spending 10x the time refactoring hoping you don't introduce any regressions.

The argument is if you specialize in young women's clothing, instead of trying to micro target messaging to different personas, have a single message that can work with everyone you are trying to sell to.

I often use the 80/20 rule to push back against requirements from product managers.

Identify the features that are hard to implement and provide little business value then cut them out. For the things that are important, I see if there are any adjustments to the requirements to make it simpler.

It usually an easy sell because it results in getting out the product faster. We can always do the nice to have stuff as a follow up, but more than half the time, they realize they never needed it.

If done strategically, it can prevent adding tech debt in the system.

That is short term cynical thinking.

Being able to give honest and constructive feedback is a skill that will grow your career more in the long run.

An exit interview is one of the safest times to practice that

I am not expecting anything to change, but I am going to do my best to make an impact as I leave for the benefit of the business and my coworkers.

How do they define fast fashion?

What makes it different than a budget T-shirt that you wear multiple times?

Fast fashion is more about how clothes are marketed than the inherent properties of the clothing itself.

They are the wrong layer of abstraction outside of simple CRUD apps.

If you have to check the API docs anyways, I rather define custom domain specific verbs than debate whether something should be a PUT or a PATCH.

I find testing everything through public methods can lead to excessive mocking, which ties you even more to the implementation.

I recently bought a toaster for the first time as an adult and started eating a lot more bread as a result.

Other toasting methods work, but they could take longer to set up and you have to monitor the progress along the way.

With a toaster, it is set it and forget with a single button press.

A lot of my planning is making sure the most effective engineers are working on the most important things.

It is about making sure resources are most efficiently allocated to meet the business objectives.

I know everyone learns differently, but I gained most of my programming skills just from programming.

You will study other people's code on the job and code reviews provide coaching.

Chess is much harder for me because I don't have the discipline to study like that.

With coding, I can read a quick blog post or follow a tutorial, then immediately start incorporating ideas into my work.

In chess, if I study something, I might not encounter a situation where I can use that knowledge in game for a while. I don't get that immediate reinforcement so I forget things much easier.

I've A/B tested hiding functionality and reducing info density increased the number of people spending money on the site.

I was completely shocked by seeing those results initially and dove deep to look for any other negative effects from these changes but could not find any. I've repeated similar tests and the results are often similar.

From that experience, I've learned that most people are not like me or the HN crowd. The things that you complain about could actually make things easier for the majority.

What is the definition of done?

My issue is that much of Agile in practice ignores the first value and puts process over people.

This is especially true with Scrum.