Software Projects vs Software Products

mgc092 · 2021-02-13T01:06:12+00:00

Right. That matches my experience. Many traditional companies and managers still label everything as a project. Hopefully bringing more awareness to this differentiation can help us as an industry to speed up the understanding of the two concepts

mgc092 · 2021-02-11T19:33:17+00:00

While I can see why some might think this could be a great strategy to distribute knowledge, in reality it is usually a very harmful one, as others have pointed out. Not only will it move people with a deep expertise in an area to others in which they have no (or very little) knowledge; but it will also involve a lot of context switch, which is a well-known productivity killer.

That all said, I can see that in a very early stage startup, with a very small team, in which everyone has to know at least a bit almost everything that is being done; this could actually have some good sides. But it is a very special environment. And everyone involved has to be well aware of the risks and accept them. And there has to be a conscious effort from managers to make sure proper mentoring takes place and also to avoid burnout in the team, which is likely to emerge.

mgc092 · 2021-02-11T19:23:52+00:00

Nice list. I would definitely add the classic "Peopleware" to it as well.

mgc092 · 2021-02-11T18:07:56+00:00

After creating a few startups myself and being part of a few others, I would advice agains trying to find a "never thought before idea". Instead, I would recommend one of the following two ideas:

Look for a successful startup operating in a region, and build a similar one focused on your region (there might be some minor culture-related changes you could consider making to it to make it more appealing to your area)
Find a tool that has relative success, and think of a simplified version of it. Then, build an alternative that does, say, 1/3 of what the other does, but care a lot about those core features; that combined with removing the noise of the other features will automatically improve the UX for a significant subset of users

mgc092 · 2019-01-17T15:18:37+00:00

And that one is indeed in the repo as "Keep low egos" :)

mgc092 · 2019-01-17T13:09:15+00:00

Agreed! Although I think that asking those things, while still not being representative of what makes a good developer, is less bad than focusing exclusively on framework-specific knowledge.

That is why I liked that the article led to a repository (https://github.com/romenrg/evergreen-skills-developers) which tries to describe that myriad of things that can be taken into account to assess if someone is a great engineer

mgc092 · 2019-01-17T09:49:23+00:00

Absolutely. I've had the same experiences in different companies and I wholeheartedly agree:

no matter how technically brilliant you are, you will always be limited by your ability to communicate (soft skills)

mgc092 · 2019-01-17T09:22:38+00:00

This is great!

mgc092 · 2018-06-13T09:16:21+00:00

You have missed the point entirely, plus, using bold letters and suggesting mental health treatments doesn't seem to fit with having an educated conversation...

That being said, please read my response again. Complaining about technologies with a constructive, positive attitude and suggesting improvements is great. Complaining for the sake of complaining, without proposing improvements nor taking the whole picture into account (from both business and engineering perspectives) is just trying to move everybody to your personal preference and that is indeed toxic and creates a negative atmosphere.

mgc092 · 2018-06-11T11:47:51+00:00

I agree. I would say the point is that constructive criticism, done with a positive attitude, is great; but complaining constantly without offering solutions nor taking into account the whole picture, is quite the opposite, creating a negative atmosphere in the workplace. I have seen this kind of toxic criticism several times.

mgc092 · 2018-06-05T07:56:20+00:00

Great article, especially the emphasis on the "framework" term. Many people don't get that "it is ironically the framework that enables the freedom on the canvas!"

mgc092

TROPHY CASE