mobjack

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.

A lot of playing politics is just knowing the type of extra work that will get you promoted.

I read about spring's best practices and think some are unnecessary boilerplate code without any real benefits.

I get the theory, but in practice, the benefits are just theoretical. You could reimplement interfaces for your tests, but it is easier just to use a mocking library.

I prefer documentation with sparse text and lots of diagrams and images. It provides the high level context and I can fill in any gaps with a short follow up conversation.

For most people, the high level information is all they really need. The few who need to dig in more can hash out the details in a smaller more effective meeting without wasting everyone else's time.

I often see engineers having a cynical self defeating view of the business. They will blindly follow complex requirements while complaining that there is not much they can do about it.

But if you demonstrate that you understand things from the business perspective, they are much more receptive to making adjustments.

Product managers like to gold plate things as much as engineers. There is usually some fat you can trim from the scope to make a deadline.

It is a measurement problem.

Android users are more likely to use Gmail which proxies the images so you can't tell what device it was opened on.

Customer complaints usually determine the spec.

If enough people wrote in about not accepting one letter email addresses, then they would likely update the validation.

But if customer service tells users to use another email address in that scenario and the customer does that, then it might not be worth the effort to fix it.

There are some privacy reasons for it.

A direct link from a search page will let websites see the search terms that users entered in to navigate there.

Google still knows everything so it doesn't protect you from them, but websites are more in the dark what users were doing before clicking the link.

Based on analytics of the website for my company, only 5% of users have a medium browser width.

Instead of designing for three screen sizes, it is easier to design for two and give tablets the mobile experience.

It is also the most challenging size to design for as you are restricted with horizontal space compared to the much more common desktop size.

Sounds like onboarding emails for new customers.

Some product manager sees that new users aren't using all their "great" features so they schedule emails to educate them.

They will stop after all the emails in the series have been sent out.

That is the problem with the tech debt analogy. There are many times you can get away with dirty code with no costs.

I wasted time before cleaning up code only for it to be dropped or for the code not needing any additional updates for over 5 years.

You can't always anticipate tech debt in advance so it often better to leave the quick and dirty solution and revisit if it becomes painful to update in the future.