This has a mirror point of view: many developers have a way of working that excessively focuses on abstract details (refactoring, optimization, obscure edge cases, niche features) which in the end often simply means staying in their own really technical comfort zone, procrastinating the shipping of a truly functional product.

I think the solution is simply integrating competencies, investing 80% of your time on the core skills and spending 20% on collateral ones. Improve the variety of your skills and put yourself in others' shoes. This 20% permits overlapping others' core skills, creating a valuable collaboration.

And finally, don't forget to listen to the end users.

nostr:nevent1qqspw6tt2awlug7707zguv8vmhwnwlt02h8wtv7k98cus8wxsq97ypgprdmhxue69uhkx6rjdahxjcmvv5hxgar0dehkutnrdakj7q3q0000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsxpqqqqqqzuvcsqe

Reply to this note

Please Login to reply.

Discussion

end users are retarded and just want a faster horse

You are oversimplifying.

More importantly, why call you a retarded?

Because you are an end user, somewhere.

good point, but then explain what you mean by listening to users.

if you mean the majority of people people they will want a faster horse

and if you listen to specific feedback from specific users you'll choose them based on your own bias

because ultimately every user wants something completely different if you ask

I mean that a team should not be a presumptuous echo chamber.

Listening to external requirements, ideas, compaints is needed, if you are creating a product for others and not only for yourself.

How to discriminate what to approve is wisdom, experience and product vision (maybe you are targeting *other* users). But just watching to the numbers/frequency usually is a good start.

makes sense and I can agree now

i enjoyed the article.

says a lot of stuff i get in trouble for saying.

In my career (devops) i have frequently encountered being subject to work that is 'tossed over the fence'. so much so, i do not believe a good team or collaboration has any fences.

I am always debugging other peoples code, and im good at it, I am not as good at writing code as I am at fixing it, but in devops "the buck stops here". There is no fence left to throw things over. Many a 3am oncall, debugging an entire stack to find and hotfix a bug that was not of my making. SQL, git, frontend, mobile, backend, queues, etc you name it.

In the world of nostr, 'the fence' appears to be: yep, its design. Another one is, users that want to 'help test' but gleeflully refuse to mess around in github issues. I see you are saying another fence exists between devs and marketing? but I am unsure because I do see devs making best efforts here as well (and yes, it wont be as good as someone who specializes in this).

Fences usually only grow tall in larger orgs and when left unchecked, and it slows everything down and makes the collaboration miserable (because one of the teams will be saddled with the ever growing majority of the work while the other remains aloof in their perfect world, and quite frankly, bored because they have effectively blocked themselves from the responsibility of completing anything).

All that being said, this is why I really like V4V because I think everyone when given a chance would prefer to provide the maximum value of their expertise in a granular (hourly) fashion. This way, the fences are ok because its much quicker to 'get done' and move to the next project and its very clear what was done and how much effort/time it took vs. what is needed to complete a project.

my beginning in tech was as a troubleshooter and that put me as the "fence" for even teams that i was not part of, so it taught me some stuff about being careful in this tech debt situation.

not to say that my own work has been at times messy but when someone actually cares to use my work i want to make it like teh Taj Mahal or something.

getting that pretty intensely now, currently putting nice informative godoc comments on everything in realy so the people who are now starting to be "over the fence" from me don't have to decipher my sometimes terse code.

> I see you are saying another fence exists between devs and marketing?

I refers to devs and designers.

But I suppose the same concept applies to marketers, product managers, content creators, etc.

To be honest, sometimes opensource developers, controlling the most valuable part of the project (the code), create a fence around themselves, thinking that what they do in the non-core areas (often design) is just enough, and so they ship mediocre products. This happens only because they do not apply the 20% rule; learning other skills would be enough to highlight the limitations of the current situation and create the urgency to seek help.

saying its only 20% is prob underestimated, but, yes, i agree everyone can and should do this.. esp now with AI. unfortunately, opensource never has a budget for things so saying they can seek help, this only really happens organically as a project matures over many years with a larger base.

Shipping and solid functionality, are usually more important than looking nice for opensource, because even the nicest looking interface that fails to deliver its goal wont get the traction it needs to survive long enough to result in power users coming onboard to help.

If you think that design is just "looking nice" you are severely underestimating its potential, especially when paired with product management. A technically robust feature that no one uses because it is not accessibile, doee not exist. A lot of interesting open source software unfortunately do not exist.

we are still talking opensource here right? 😂

for me, im already out on the limb by pushing so far up the stack into frontend, if i cant get a tailwindcss component, im basically DOA with these figma jpgs.

this is not a complaint. i dont really expect anything as i am not paying anyone. if i did you can be sure id expect a lot more.

i can't even comprehend how front end shit works... this works, but not that, you can put this with that, but not that with this, 3 months i fought with that shit and i was like "i never gonna make front end"

yet i can literally now practically write a full bitcoin client from scratch

whatever those front end cunts are doing requires LESS intelligence and curiosity than i possess

You had the courage to step out of your boundaries and you did a good job!

i wrote a reasonably decent, responsive UI in pure go about 5 years ago

it's not that i can't think about how to build these things, i literally even from scratch wrote a proper scrollbar for a library that didn't have one

good luck finding a javascript ninja who can even comprehend events and scaling and representing data graphically

they literally can't, and the people who can make them with javascript make all these libraries that can't be used at the same time with each other, because this thing or that thing

it's a void into which i'm simply not going to waste my time going because i like to be able to reason about my code.

thanks, i tried. i guess i can feel good about it, i know it's not the best, but it's the results of probably hundereds of hours of me pushing out of the comfort zone. i just upgraded nextjs, tailwind and daisy too, and it went so flawlessly i had to give myself a pat on the back on that one (means i picked a good stack, and didnt use bad dependencies) 🎉🎉🎉

this is why i don't negotiate with javascript

you have to fit your app into whatever shit they make because you can't extend or recompose that shit because it's fragile as styrofoam

the problem for new devs is that there are so many unknown unknowns. we don't know what the core competencies are, so by that logic - prioritizing making the unknown unknowns KNOWN unknowns would make sense.

The new problem becomes - how to do that, and the only solution I've come to is to try to read more, a lot more, and try to read deeper, better things.

Would love to hear other peoples thoughts on the topic of making unknown unknowns known unknowns.