• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

I make lots of mistakes (No 2)

 
Marshal
Posts: 79412
377
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The more threads I start, the better my chances of winning the book

Are you looking at serious mistakes or trivial mistakes? Is there such a thing as a trivial mistake at all?
 
Saloon Keeper
Posts: 27861
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Do we do it by threads, or by posts? And for that matter, I thought we just said we "randomly" select from people who post during the eligibility period.


Anyway, MOST of my mistakes are trivial. I have spent more literal days chasing a misplaced comma than I ever have working through some gnarly algorithm or talking to a complex subsystem.

In fact: I had to rebuild a server last weekend — an unexpected thunderstorm apparently got past the power conditioners and blew out the system drive. Spent all evening not getting it to re-provision off a PXE boot. Got up next morning and realised that the DHCP server thought that machine's MAC address was located on a different machine altogether — I'd missed updating the DHCP data on a previous server swap-out.
 
Campbell Ritchie
Marshal
Posts: 79412
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:. . . days chasing a misplaced comma than . . .

That isn't a trivial mistake then. How did such mistakes show themselves? Compilation failure? Crashes at runtime? Or incorrect results? That last is of course the most serious.
I don't know how winners are randomly selected, but I always thought it was by posts.
 
Tim Holloway
Saloon Keeper
Posts: 27861
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The mistake is trivial. Any beginner can spot it. I can't because I "know" what's there and thus can't see it's not there.

The fix is trivial. Once spotted, it's like "move cursor here, type comma, save/build".

The results are not trivial. Since I do extensive anti-bugging, it rarely shows in production code, but development and testing often grind to a complete halt while I try and fix that one nastly little error.
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is where code reviews and pair programming come in.

I've been in academia for a while where, unfortunately, such things are frowned upon as somehow "cheating", but multiple pairs eyes on the code has saved my bacon many times in "the real world" ;)
 
Author
Posts: 13
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Are you looking at serious mistakes or trivial mistakes? Is there such a thing as a trivial mistake at all?




The book is intended for engineers and architects that already have some experience in the industry, so we are focusing not on trivial mistakes.
However, the more experience you have, the more things look trivial, so if someone with really great and long experience reads the book, maybe one or two mistakes may look trivial to them
 
Tim Holloway
Saloon Keeper
Posts: 27861
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Frank Carver wrote:This is where code reviews and pair programming come in.

I've been in academia for a while where, unfortunately, such things are frowned upon as somehow "cheating", but multiple pairs eyes on the code has saved my bacon many times in "the real world" ;)



I've a rather jaundiced view of code review as a meeting where others gang up on you, and pair programming as "cram 2 people into a cubicle and fight for the keyboard". Unfair, perhaps, but even the best concepts are prone to corruption, especially when they become part of the corporate religion.

I don't typically need continuous monitoring, and in fact, it can be distracting. But being able to grab a random junior programmer and have them take a quick look has saved me more than once.
 
Campbell Ritchie
Marshal
Posts: 79412
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Frank Carver wrote:. . . I've been in academia . . . such things are frowned upon . . .

They should be teaching that you are taught to program individually, but in the real world most people program in pairs.
 
Tim Holloway
Saloon Keeper
Posts: 27861
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:

Frank Carver wrote:. . . I've been in academia . . . such things are frowned upon . . .

They should be teaching that you are taught to program individually, but in the real world most people program in pairs.



Never have. I'm usually sole designer and implementer, whether I want to be or not. I had a flunky for a few weeks once. Sadly, he moved on. I missed him.
 
Tomasz Lelek
Author
Posts: 13
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

...program in pairs.


It also depends if you are working in a remote-first company or on-site at the office. I am also not a fan of pair programming.
 
Frank Carver
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have got a lot out of pair programming over the years, and also a lot out of code reviews. Just like everything else, though, there are different ways of doing these things, and some work better or worse for different people.

For me, pair programming is a very intense experience. It feels like being 100% "on", and this is mainly due to the extreme accountability of someone else looking at the code as you type it (or concentrating on the code your partner is typing) Because of this intensity, I can't do it for long periods (although, like gym time, you can build that stamina with repeated practice) After a pairing session, I always need some alone time to digest what we have done, and catch up with all the other things which might have distracted me if I was working on my own (cough Code Ranch)

Pair programming also needs trust. Both partners need to trust that the other is paying attention and pulling their weight in the process. It also needs a good balance of skills.  If only one person is contributing, it becomes just another weight to drag along.

When you get it right, pair programming can be very productive, and produce great code, but it's not for everyone. Like so many practices which originated from developers, it can easily chafe when imposed by management.

Code reviews have some of the same benefits and drawbacks, and can be considered as a kind of asynchronous pairing. Code reviews need trust and a good balance of skills, but they also need good communication skills to explain what has been spotted or ask why something is as it is without causing confusion or offence. Unlike Pair programming, code reviews can work pretty well with non-developers such as business stakeholders by walking through a solution and explaining it in the language of the problem domain rather than the language of code. I have seen this catch misunderstandings many times.

A good code reviewer, like a good editor for a writer, has to be someone who you genuinely want feedback from, and who you know will pay attention to the details and catch things you have missed. Just as with pair programming, Code reviews can just be a huge waste of time if they are mandated as part of a process, particularly if that process requires developers to send code out to multiple people and wait for their responses. On the other hand, code reviews can be hugely useful if the team has a culture of shared responsibility, and developers are encouraged to seek an appropriate person to take a look before pulling the trigger to deploy.
 
Sheriff
Posts: 17652
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tomasz Lelek wrote:

...program in pairs.


It also depends if you are working in a remote-first company or on-site at the office. I am also not a fan of pair programming.



What made you not a fan? Any specific experience(s) that soured you against it?
 
Tim Holloway
Saloon Keeper
Posts: 27861
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I cannot abide distractions of any kind when I'm in the groove. I'm quite willing to hash over ideas before the fact, and periodically during the fact, but having someone play back-seat driver to the code while I'm slapping it down (I do a LOT of moving stuff and refactoring while coding), nope.

Back when I was doing assembly language and optimising every line, it was literally painful to withdraw, even for lunch breaks. Basically, it's an intense meditative state and I've yet to head of "pair meditation". One of the reasons I like today's language environments. though --- I can offload a lot of the optimisations onto the compiler and only have to worry about the higher-level stuff.

You can call me arrogant, but while I do often get dinged for the time it takes me to produce software, once it's done, none have ever taken me to task for its quality.

My processes work for me. I cannot speak for others. I generally get assigned the really critical projects, not the team projects, so Your Mileage May Vary.
 
Junilu Lacar
Sheriff
Posts: 17652
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I will say that there are pairing and even mobbing/ensemble situations that are frustrating as heck, especially if you're trying to get something done and there's more discussion than there is action.

When a pair/mob/ensemble gets in the groove though, they will tend to produce better code than the solo programmer. There are, of course, exceptions to this. I would even go so far as to say a really good developer can do better than the average pair/mob/ensemble.

You do lose out on quite a few opportunities though. The opportunity to teach less experienced or newer developers and give them a deeper understanding of how the design evolved into what it is now, giving them the experience of being part of the decision-making process on where to take designs, giving them tips on better ways to implement ideas, these are just some of the intangible but invaluable things you lose. That's assuming you can get to a level of maturity of collaborative development that goes beyond pure dictation (do-this-not-that) or a follow-along-and-keep-up-if-you-can situation.

Collaborative development is hard and it takes a while to master but when you're doing it with folks who know how, it's much more fun and in my experience, more productive.
 
Tomasz Lelek
Author
Posts: 13
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

What made you not a fan? Any specific experience(s) that soured you against it?


I feel there is a high probability that the person with stronger opinions and character may dominate the pair programming.
Also, I think that everyone learns and processes things at different speed. It's hard to pair two engineers that are processing and coding at a similar rate.
 
Frank Carver
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:The opportunity to teach less experienced or newer developers



This is a key point, I think. There's an analogy with Test-Driven Development in here somewhere, let's call it Training-Driven Development, TDD  ;)

A long-term project lives or dies by the quality of the maintenance. Initially it seems great to have a single developer who has a deep understanding of everything and can solve every problem quickly and efficiently, but eventually that developer is going to move on. What happens after that depends on how well the successors share that deep understanding.

I have spent most of my career as a contract developer, typically brought in to work on codebases which have grown horrible through years of suboptimal fixes and "improvements". The story is almost always the same. A single hero developer (occasionally a small team) who was always too busy or too secretive to explain why and how. Then the hero moved on to a new project, beginning the decline into a ball of mud.

Techniques such as pairing (and, as Junilu points out, mobbing) and code reviews seem like a needless slowdown, just as writing tests seems like extra work which just gets in the way when you know you are writing good code.

Test-Driven Development has gained a lot more traction, though, probably because the benefits pay off sooner. But the analogy holds, and investing in the future through immersive training has a place too.

I'm not going to claim that these training techniques should always be used, though.

I'm a huge Test-Driven Development fan (you only have to look back at my Ranch history to see that) but even I admit that it's not always appropriate. Some will only have a very short life, such as the data analysis and graph drawing code I am currently writing for my PhD research, and the overhead of writing tests is pointless. Likewise, some projects will be so personal or so short-lived that they will never be handed over to other developers. In those cases the overhead of training successors is also pointless.

But in the context of a complex, long-lived project, succession planning and training is as important as any other "non functional" requirement. In such cases, collective ownership, pairing/mobbing, and code reviewing are some of the easier ways to integrate training in with the day-to-day development work.
 
Tim Holloway
Saloon Keeper
Posts: 27861
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Frank Carver wrote:
I have spent most of my career as a contract developer, typically brought in to work on codebases which have grown horrible through years of suboptimal fixes and "improvements". The story is almost always the same. A single hero developer (occasionally a small team) who was always too busy or too secretive to explain why and how. Then the hero moved on to a new project, beginning the decline into a ball of mud.



One of the things I've seen over and over is that the most successful and essential projects for a given site were generally knocked out over a fevered weekend by one or two people, thereafter to run, with minor mods, for literally years thereafter; if the system goes down, often the whole shop effectively goes down.

The architecture is often sketchy and the code is frequently horrifying, but "it ain't broke, so…"

Now eventually all good things must come to an end. The system needs an overhaul that's just too extensive to simply patch in. This can be a cue for expensive Dogberts to come in and recommend very expensive development products and restrictive development processes, hiring a full development team, lots of meanings, and plenty of dust and noise.

And they'll thrash around for many months until they realize with horror that the deadline is fast approaching and the budget is blown. And not infrequently, the whole revamp ends up being trashed, and the company limps by until some new does a hack job.

It is true that the original system will often be effectively undocumented. Often one of the first things I've had to do when inheriting such a system is write a manual for it.

It's worth noting that when Fred Brooks first introduced the Chief Programmer Team concept in his seminal work The Mythical Man-Month, one of the specialist positions on the team was "Librarian". CPT, of course, didn't last long. Why hire 5 people when you can dump all 5 distinct jobs onto one or two people? And Librarian was just too much.

As it happens, I'm of the stripe that writes the comments before the code, and my comments tell what a given component is to do — and how to deal with surprises — and not how it does it; as the code itself in modern high-level languages is generally pretty clear on most of that. Donald Knuth gave this concept a formal title: Literate Programming, and even a tool to go with it ("Web"), but it's always been a practice of mine. Consider it an aspect of ADHD. After a while, a project gets boring. If I've documented it well enough, I can dump it on someone else and run away!

Edit: quote originally attributed to Junilu. Sorry about that!
 
Junilu Lacar
Sheriff
Posts: 17652
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tomasz Lelek wrote:I feel there is a high probability that the person with stronger opinions and character may dominate the pair programming.
Also, I think that everyone learns and processes things at different speed. It's hard to pair two engineers that are processing and coding at a similar rate.


I have seen this. Collaborative development is a skill. Egos have to be checked in at the door. Strong opinions have to be tempered with patience and willingness to experiment with other approaches.

Having a good working agreement before you start helps. Agree on how to make the interaction more collaborative, inclusive, exploratory. I find that the 10 Commandments of Egoless Programming is a good starting point. I find that code written down is far more convincing than code imagined, whichever way you're leaning about an idea.

After every session, have an honest and open retrospective on what was good or bad about the session, what you might do differently next time. The retro doesn't have to be very long or in-depth. 10-15 mins max will do. Most of all, practice deliberately and with a specific learning goal in mind. This was how my team and I got better at it and the basis for how I coach teams on it these days.
 
Junilu Lacar
Sheriff
Posts: 17652
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
These are some of the things that keep coming up in retros on collaborative programming:

1. It's better to start with a rough idea of the overall design, even if it's just a straw man.

2. An idea always looks good when it's in your head, especially if it's your idea. Writing it down as code reveals flaws much faster. Writing tests around the idea flushes out bugs.

3. Arguing about the merits or lack thereof of an idea is usually a huge waste of time. See #2.

4. Always experiment on a branch to try/prove out an idea we're not sure about yet.

5. Have a specific learning goal in mind for each session.

6. In the retro, ask if you achieved your learning goal. Ask if you learned anything else. Decide on what the next learning goal will be.

Note:

The learning goal can be anything, covering general programming principles, techniques, or something very specific about the program you're working on. It can be something like "We want to understand how this part of the program works / why it was designed this way."  It can also be something like "We want to learn how to apply the Strangler Pattern to this part of the code" or "We want to see if the Builder Pattern will make this class easier to work with."
 
Ranch Hand
Posts: 150
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Code Review - Praise in public, Criticise in private
 
Marshal
Posts: 8880
638
Mac OS X VI Editor BSD Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Campbell, cowgratulations, your topic has been published in our CodeRanch monthly journal: https://coderanch.com/wiki/754594/CodeRanch-Journal-September
 
Campbell Ritchie
Marshal
Posts: 79412
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for the cow
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic