I'm a professional programmer.
I have never read Design Patterns and couldn't tell you the difference between a Singleton, a Factory, or a Roundabout.
I think UML is a great way to make pretty diagrams that don't mean shit and that any code created from a UML to class generator is going to be overly complex.
I think people who make flowcharts value form over function.
I believe that documentation is way more important than any of these.
@craigmaloney okay boomer
@fluffy Pardon me if I neglect your witty retort with like and kind.
@craigmaloney i would wait for your wit, but i think we both know it’s not coming
@fluffy You kid yourself.
@craigmaloney does this look like the face of mercy
@fluffy Do I look like the sort of person to play with Markov chains?
@craigmaloney you look like the sort of person who hasn’t had an ounce of joy in way too long
why not lighten up a little? play around, we’re all stuck at home together, let’s make some fun out of it
@craigmaloney All of these tools are misused in practice. They were intended to provide meaningful standards for different kinds of documentation. They turned into process by people who wanted to sell convention tickets and speaker slots. I wouldn't ignore their documentation value, but definitely do ignore everything else.
@craigmaloney I agree with @vertigo here. The software engineering discipline is corrupt and so are its organizations - that's why these tools don't work in practice. Basically what software engineers are missing is systems engineering. This stuff has already been figured out it's just people/businesses are too lazy/cheap to implement it.
@craigmaloney I've never used or even learned UML in my life as a computer professional (did not take CS in uni, picked it up the old fashioned way through privilege and nepotism)
@craigmaloney Design Patterns is a good book misused by drones, it's not recipes but "how to identify paths you've walked". It's meant to be read after Chris Alexander's books, not instead of.
UML serves some purpose, in large systems it's good documentation; they've saved my ass in J2EE projects. The visual programming part's not great.
Flowcharts were an incredibly valuable tool for ASM, BASIC, FORTRAN, etc unstructured languages. Still are, but I mostly do pseudocode instead.
@craigmaloney Documentation's a great idea. I've rarely seen it exist, comments are always wrong, most programs no longer have a user manual or even internal help. Mostly they say "ask in discord or stackunderflow".
I barely have any, and I know its value.
@craigmaloney I laughed and I agree! At work I always groan when customers demand UML diagrams and Entity Relation Diagrams of the database. What do mean, I say. We have hundreds of tables, thousands of classes, millions of lines of code. You need to ask a particular question and then we’ll answer the question, maybe use some custom made diagrams, but otherwise my answer is simply: your printer is not big enough!
@Sandra why don’t you apply for the job.
Yeah, I’m definitively interested in serious job offers.♥ I’m pretty broke at this point. Is it possible to work remotely from Sth part time? What kind of job is it?
Or is the question rhetorical?
Look, what I mean is that when someone says what I quoted, one of two things come to mind. Ideally the code is clean and elegant and well factored (with metaclasses, well normalized relation tables etc) but the problem domain is Just So Huge, each client a little different etc.
The other architecture that comes to mind is — and I’m not saying that this is true for your workplace, I’m just saying that it’s what might come to mind for some people when they hear that — is a redundant huge mess of cut&pasted nested if statements.
So rather than saying “@email@example.com, your code is a mess”, I’m trying to say “ah, watch out, people might hear that reply and mistakenly take that as your code being a mess”.
So, if it were rhetorical rather than a job offer, I read that as you being upset and I wanna apologize. I know work can suck. All my sympathy♥ (← if it were a serious job offer I am really really gonna regret making this post)
Design patterns are really great to deal with the shortcomings of Java, SmallTalk, Ruby and Python. For people stuck using those systems I strongly recommend them. The original Gang of Four, the goofy&commercial “Head First Design Patterns”, and the curious “A Little Java” are all books that have helped me.
Thousands of programs are built on the MVC pattern and understanding it is pretty key.
For other languages, those specific design patterns aren’t great but the general idea is. Or “paradigms” as Norvig calls them.
The design patterns community, or at least adjacent, also have refactoring catalogues and those are absolutely amazing and a lot more universal. Even lisp dorks can have something to learn from https://refactoring.com/catalog
Re flowcharts—remember that they came from the age of GOTO (and then a second wave—UML—with OOP). Obviously with modern languages and tools you don’t need them. But if you are stuck using an OOP language it can be somewhat good to get an UML overview so you can see how everything fits together in your architecture. Ideally you’d want to autogenerate it from code or vice versa instead of implementing everything twice. But UML / flowcharts are not necessary by any means.
@Sandra My biggest complaint with UML and Flowcharts is the "holding it wrong" issue, where the form is more important than the information it conveys. It's having to remember a bunch of things in order to use it when a simple line-diagram with text could convey as much information with less tools to make it.
And like others have stated, once the code starts flowing those diagrams suddenly become a liability as things change.
@Sandra I know they're useful for some but I've seen them wielded as a club more I've seen them used as a shovel.
Same with Design Patterns. I've seen more folks trying to get the jargon right than actually solving the problem.
I'll admit that I was late-night cranky and glib with the original post.There's definitely some value in these tools, but like others mention they have a mysticism and ritual to them that I feel can lead people to believe they're the only way to truly get it right. ,,,
@Sandra It's that mysticism and ritual that I find disheartening in our industry. Worse, it's also used for gatekeeping as a type of impromptu test that one can use to cred-check those who haven't put in the time to learn the ceremony.
This post was also brought on by a Game Mechanics (Design Patterns) book that I leafed through again and realized that we really do love our rituals and ceremonies when it comes to algorithms, regardless of their forms.
@Sandra (Thank you for your thoughtful reply. You gave me space to think more about this, and I appreciate it.)
that we really do love our rituals and ceremonies when it comes to algorithms
Constructing Lego pieces out of smaller Lego pieces, and then building bigger Lego pieces from those Lego pieces, is a sort of lever that can amplify human thinking. For good and bad.
I’m definitively not going to try to argue about both of those very serious caveats re diagrams. They are issues and risks you do need to be mindful of if you bring in diagrams.
But flowcharts and diagrams came from an era of languages like Pascal, Cobol, Fortrand, Assembly. Those languages can really benefit from an external tool — that can mean diagrams, or that can mean macros or code gen (I personally would probably whip up a DSL). I don’t fault someone in 1975 for doing a JSP diagram before opening the editor. Diagramming and structure visualization, carefully applied, have on occasion saved me months of work.
Design patterns, on the other hand, I will stand up for. Getting the jargon right is a legit way of solving the problem, rather than a side track. I mean, ultimately, it’s the human compiler at work, and if you used a real language you wouldn’t need Visitor or Template Method. Some patterns that are absolutely vital to get OK Java or Obj-C look like ridiculous jokes to a Lisp head. The Lisp solution is to extend the language programmatically instead of lexicalizing/codifiying idioms on the human/practice level. On the other hand, that is also a kind of design pattern, just on a different level.
Alexander’s original A Pattern Language is one of the best books I have ever read. Love it to bits.
@Sandra I really need to read "A Pattern Language". Do you recommend reading the first book in the series first (A Timeless Way of Building) or does it stand on its own?
@craigmaloney Start with A Pattern Language
@Sandra Thanks. Adding to the list.
@craigmaloney In one of my early software jobs I was officially the "software architect". I spent weeks creating highly detailed designs for modules and how they would interact, with neat diagrams. Part of my formal training in software had also been about doing this. You start at the high level and break the problem down into increasingly smaller chunks with well defined interfaces which can then be handed off to coders.
And of course as soon as the implementation started my neat diagrams went completely to hell. So it was really all time wasted.
A lot of my early reading about software was during the "mobot" period of the MIT AI lab, so my approach to software is similar to subsumption robotics. Software grows and has emergent properties. It's not like designing bridges or other classic civil engineering. It's more like gardening.
This is an old story, weaker developers follow cargo-cult behavior patterns they see in strong developers.
But thing is, this didn't occur in a vacuum, those of us who are 100% on top of our game need to take some responsibility for creating the culture where a novice is better off banging the table with their SingletonVisitorFactory flashy nonsense than admitting when they don't know how best to approach a problem.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!