5 ms·
> They have a big appetite for adding complexity to systems .... What was notable, though, was his immediate willingness to write that feature. From your descr
by rgoulter 4y ago
> They have a big appetite for adding complexity to systems .... What was notable, though, was his immediate willingness to write that feature.
From your descriptions, it seems less about "adding complexity = good", and more about "solving things in a neat way = good" (for some definition of 'neat').
> Do you have any thoughts on how to work with them in a productive and friendly way?
I'm not sure you've articulated the problem very well?
It sounds like if they left & the code was handed to you, you'd be concerned about hard-to-spot bugs in the sophisticated code. -- But if the code & its correctness is your colleagues responsibility (& not yours), what's the problem?
> It boiled down to me advocating for more whitespace in his code and him arguing that adding whitespace made the code harder to read.
I think you came to the right conclusion about the differences. But, you might enjoy this blogpost from Steve Yegge:
http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.htm...
- stingraycharles 4y agoI think what you’re trying to say is that these types of solutions are fine, as long as they are decided upon by the entire team, and not just a single engineer: long-term maintainability is key here. I’d also argue productivity is an issue: “neat” solutions may take much longer to develop, while the effort is not really justified. E.g. starting out with a system based on CQRS which is just a simple CRUD app.
- noduerme 4y agoJesus fuckin Christ. I tried to read this blog post about how newbies make their code comments too verbose, and the post turned out to be longer and about as interesting as fucking Dianetics. tl;dr, young programmers, ignore that schmuck. Please keep writing nice long comments to your heart's delight. You will thank yourself one day.
- rgoulter 4y ago> about how newbies make their code comments too verbose I don't Yegge is trying to make this point. Instead, he's making a similar observation to the discussion OP had about whitespace/code: Yegge reckoned that someone who's very familiar with the program/domain will want to have very dense code, so then they can make as much use of screenspace as possible. Whereas, for someone who's unfamiliar with a domain will benefit from seeing less code on the screen at once. It will be easier to digest. I don't really see that as a value judgement where "comments = bad".
- dusted 4y agoOne of us missed the point because I just added that to my permanent bookmarks as an excellent explanation of why some people write overly verbose (and hard to read and thus maintain) code, while others manage to write the same thing in a single, understandable screen-full. " I would rather puzzle through a small, dense, complex piece of code than a massive system with thousands of files containing mostly comments and whitespace" <-- This, a thousand times. _I_ simply don't have the capacity to load giant nonsense class hierarchies into my head and actually execute such a program.. A small machine that I can actually see on on the screen, that I can manage..
- noduerme 4y agoreally... if you've ever tried to write your own functionality into something like wordpress or bootstrap or whatever, you'd rather have that all in a single code file with less white space or comments? Would that make it easier to change the positioning of a particular dialog box? I thank God all the time for the white space and long comments left by writers of those kinds of libraries. Maybe those seem like trivial examples, but they're huge libs that don't often need a lot of changes; yet when you need to change things, they make it quite easy to find. [edit] as I wrote that, I just realized that younger devs might actually look in horror on the idea of directly editing libraries like that for particular deployments because the tooling or shop mentality so forces automated upgrades that could overwrite custom changes... and institutional memory being so short, no one might remember the change some dev made to a bootstrap file. heh. But that's like someone calling themselves a mechanic without ever modifying an engine. You write a note, commit it with a custom marker like #weModifiedThis, and don't upgrade the library for 15 years or until you're dead or retired or the company goes out of business. Done.
- dusted 4y agoThere's a balance to being overly verbose and isolating _EVERYTHING_ from _EVERYTHING_ to such a degree that it's a major travel all around the codebase to follow one little path through a single call, and cramming _EVERYTHING_ into one file. I'm arguing for a balance.
- rowanG077 4y agoWow. I would LOVE to only work with "noob" programmers who nicely explain their reasoning for complex code. Comments are easy to ignore anyways.