411–420 of 704 posts
Almost 20 years of professional experience here: I fully agree with this list. I even want to add a few things: > Clever code isn't usually good code. Clarity trumps all other concerns. My measurement is "simple and clean" code. Is it simple and clean? No? make it so! > After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. If a good developer you…
daily updates are a chore and pretty useless rather than for the "manager" who has to check on people's work. I have been in places where we had one update every week or every other week and that was the proof (along with other places I have seen) that daily update is just a waste of time. This article summarises it for me "Daily Stand-Up Meetings Are a Good Tool for a Bad Manager" [0]
[0]https://www.yegor256.com/2015/01/08/morning-standup-meetings...
Earlier quoted context omitted.
I think the best part of doing test driven development (or similar) is that making your code easily testable generally also makes it architecturally sound.
Refactoring is quadratically more difficult if you don't have tests.
Have never agreed with a blog post more. Every single bullet point, 10/10. Okay, okay, actually I have one qualm~ > Standups are actually useful for keeping an eye on the newbies. Unfair. Standups are useful for communication between a team in general, if kept brief. If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently lo…
Every time I mention the goodness of pencil and paper I get downvoted by so many youngsters. Some people will always disagree about some points. It's in their nature.
Almost 20 years of professional experience here: I fully agree with this list. I even want to add a few things: > Clever code isn't usually good code. Clarity trumps all other concerns. My measurement is "simple and clean" code. Is it simple and clean? No? make it so! > After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. If a good developer you…
I can add a few things:
* Operational considerations dominate language choice.
* Architecture too.
* Politics, leverage and all that MBA crap dominate all of that.
* Language zealots are net negative idiots and need taking outside and shooting.
* Actually apply that to all zealots.
* The root cause of the above is often insecurity; and it can be coached / cultured away.
* If your lead/management doesn't get that then they're in the wrong job, get out.
* If you see shady consultant types and "thought leaders" talking about something, then it's just the latest bullshitchain.
* If you see a junior developer say "this is easy", then let them learn the hard way, but manage expectations.
* If you see Senior level engineers constantly say "this is easy" when the problem isn't clear, then run for the hills
* The 10x engineer is only true in special cases and does not generalise.
* That ^ is why you need to work together so everyone is doing their 10x task.
* Incompetent engineers and bad actors can act as negative 10x engineers.
* The vast majority of people on the outside of the team (consultant types) are worse than the above.
Earlier quoted context omitted.
If I were an evil tech giant, I would open source a bunch of libraries that require significantly more effort to use than necessary, and pitch them as the One True Solution. Just to slow my competitors down.
I had a nemesis who would steal all my ideas. So I bought all the XP books, dog eared them, left them on my desk. My team nearly mutinied. I asked them to wait and see. Two weeks later, nemesis announced his team was all in for XP, Agile, pair programming, etc. They never recovered, didn't make another release. I tossed my copies, unread.
> Clever code isn't usually good code. Clarity trumps all other concerns. I'm glad I'm not the only one who thinks this way. I've had countless arguments with colleagues about this, and they always made it seem like I was the crazy one for thinking this. They would often optimize or use clever tricks in their code, to the point that unless you asked that specific engineer, nobody would understand it. In most cases, t…
Ask them a specific question about their code three months later.
Almost 20 years of professional experience here: I fully agree with this list. I even want to add a few things: > Clever code isn't usually good code. Clarity trumps all other concerns. My measurement is "simple and clean" code. Is it simple and clean? No? make it so! > After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. If a good developer you…
Your mention of simple and clean code makes me think of the excellent talk "Transforming Code into Beautiful, Idiomatic Python". Although it relates to Python programming, if the ideas and principles (and thoughtfulness and pace) from it could be applied to much more written code, then (I think) we as an industry and all our users would be in a better place. [1] - https://www.youtube.com/watch?v=OSGv2VnC0go
With that caveat, watching almost anything that Raymond Hettinger presents is positively correlated with improving programmer skill.
Earlier quoted context omitted.
In theory, no difference. In practice, good standups to me always feel like a casual conversation, and bad standups always feel like people speaking off a script like bad actors.
If one had to troubleshoot a bad standup meeting, how might you turn one that feels more scripted into one that feels more natural?
Earlier quoted context omitted.
Agree with this wholeheartedly. Standups are annoying but I have learned they are necessary, even as a very experienced developer. Sometimes things just cone up you wouldn’t otherwise know about and it encourages helpful, meaningful communication amongst the team. What’s not helpful is when standups are treated like status reports. That’s not the purpose - even uber green newbies are responsible enough to do their wo…
> not helpful is when standups are treated like status reports > simply state what you’re doing Honest question, what's the difference.