undefined | Better HN

0 pointshasmolo3y ago0 comments

normally a developer that can't program shows in a few major ways:

1. pair programing where they "want to watch you", but never modify your code and submit it

1. talks a lot about progress, but it takes days to get a commit out of them

1. will build "solutions" to perceived problems that really only serve to make them the single failure point and are not usable

1. says shit like "i don't write tests" or "it works for me, can you show me what you mean?" and clearly has no idea what you're doing

1. you repeat the same comments in loops, because they aren't taking your feedback, they're trying to hit a KPI

these people fall into two major groups, the people doing it on purpose, and the folks that don't realize that this is them. a lot of people lie to themselves about their ability, and this is the end result of them being incapable of acknowledging that they've got work to do!

0 comments

twawaaay3y ago

Some I do agree with and some don't.

I agree on pair programming, as a tech lead, pair programming is my single best tool to get some understanding of my team member capabilities.

"Talks a lot about progress"... this is a mixed bag. In most cases you are right. But in some cases.. I have worked with people who obsess about quality of what they produce (and I am the same) who will spend a lot of time polishing things after they are nominally done. It is not that they don't deliver, they need some help defining what done is.

"Says shit like I don't write tests". I don't write tests. There are good reasons that are out of scope of this discussion. When somebody says shit like "I don't write tests" I want to hear a follow up explanation on why is it. Because if you do not write tests you have to be doing other things.

"You repeat same comments in loops because thy aren't taking feedback". Guess what, a lot of good programmers are bad in some other respects. Just because they aren't taking feedback doesn't mean they are bad. I stress to people it is not enough to be good at programming, development is about building things and programming is just one skill. Development is a team sport that requires multiple people to work together to build something.

hasmoloOP3y ago

- "Talks a lot about progress"... this is a mixed bag.

if you're producing code, it is not just talk. i'm talking about a scenario where you've heard about the great struggles they've faced, and after a week you get a commit with 4 files cahnged, and it's on a "sample" of the full work. overdone is fine and not what i meant.

- "Says shit like I don't write tests". I don't write tests. There are good reasons that are out of scope of this discussion.

This mindest is the same to me as saying "we only need a single point of failure for all things". "I can just read the source" is the same thing as saying "i can just take a course on it later that will take hours without the help of the original context". I firmly believe that anytime you build a big suite of software without tests, you're just unloading tech debt on an org with no guidance on how to handle it. comments, tips, and tricks can drift from the code overtime, a test can't and is the only provable way to validate your code. if you don't have time for testing at work it's an organizational failure that will only come due in the worst of times. Remember when Jira deleted a bunch of shit and couldn't get it back without one engineer fixing it manually? boy, i bet it would've paid to have _any_ testing in there!

- "You repeat same comments in loops because thy aren't taking feedback".

When you tell someone "commiting secrets to the repo means they are no longer secret" and they go oh yeah, makes sense, and then proceed to dump credentials into the next four commits, that's what i'm talking about. not this "i dropped a whole new concept on you. learn it in one" concept that i may have implied. i'm talking about poeple who just aren't even trying to listen, they just want an approval or w/e from you to move on.

fwiw: i'm a bit of a stickler for testing, and will acknowledge that my stance comes from my experience, and is therefore a known bias, just one i have a hard time letting go of

twawaaay3y ago

FWIW: I don't do tests because of how I learned programming writing large swaths of code for weeks that had then to work perfectly the first time (embedded C on a machine with very poor development process and external company that had to sign the binary before I could run my code). I taught myself rigorous thinking about code and various techniques that make it less likely that there is something wrong with it, otherwise I would be loosing a week before I got another chance to run it. I also then worked in a lot of projects with poor code quality and no test coverage that I had to run extensive refactors of and keep hammering on until it looked decently. With this in mind, unit tests have never been useful to me in any way and would be just a waste of time because they would not bring any benefit to anybody else I worked with.

It is not that I believe tests do not work. Tests is a viable solution to a problem. The issue with tests is that you have to do a lot of things right and you have to structure your development in certain way for tests to be productive. And if you don't do a lot of things right then tests will just cost a lot of development time without much benefits.

Introducing unit testing is hard if your team isn't already doing it and costs a lot of effort for practically no immediately visible effect to stakeholders.

Very few organisations I worked in would be at maturity level when investing in unit testing would be the highest return on investment thing you could do at the moment. There is usually many other problems that cause less disruption to development practices and bring much more benefits than unit testing.

On the other hand I am a huge fan of functional testing where you create a test harness that ensures that public interface of your product (application) functions as expected. The effort is much smaller (you only evaluate public interface which already is integrated with other things and which isn't expected to be changing a lot anyway), the benefits are clearly demonstrable and understood by stakeholders.

1 more reply

j / k navigate · click thread line to collapse

0 comments

twawaaay3y ago

Some I do agree with and some don't.

I agree on pair programming, as a tech lead, pair programming is my single best tool to get some understanding of my team member capabilities.

hasmoloOP3y ago

- "Talks a lot about progress"... this is a mixed bag.

- "Says shit like I don't write tests". I don't write tests. There are good reasons that are out of scope of this discussion.

- "You repeat same comments in loops because thy aren't taking feedback".

fwiw: i'm a bit of a stickler for testing, and will acknowledge that my stance comes from my experience, and is therefore a known bias, just one i have a hard time letting go of

twawaaay3y ago

Introducing unit testing is hard if your team isn't already doing it and costs a lot of effort for practically no immediately visible effect to stakeholders.

1 more reply

j / k navigate · click thread line to collapse