Comment by conjecTech | Hacker News Reader

Comment by conjecTech | Hacker News Reader

There is a class at Georgia Tech I colloquially referred to as "making sure your coworkers don't hate you." It covered design patterns, software testing, and project management. I'd tack on a basic knowledge of databases to that. These are things you can gain a true functional knowledge of in a couple of weeks, and which not knowing might make senior engineers hate working with you.

So to mimic the class:

The Mythical Man Month

Design Patterns - Even if some of the particulars are not as relevant, it still provides a useful framework for thought.

Lessons Learned in Software Testing: A Context-Driven Approach

I'd also add Harry Potter & The Methods of Rationality. A lot of engineers can think empirically, but its not their first reaction. Going through this book helped make it second nature for me. Can't remember if a certain data structure is immutable? Now I'll write a couple of lines of code to see rather than go looking for documentation. A lot of big problems start as false assumptions. Having the instinct to think to test them and knowing how to will prevent a lot of wasted effort, regardless of your role.

How to Solve It by Polya also gets an honorable mention for similar reasons.

Design patterns feel completely obsolete now.

Not only does no-one at all talk about them, most of the design patterns themselves were harmful and are now completely unnecessary due to functional language features being available in modern languages.

Design patterns are like TDD, no-one wants to come out and admit it, but they were really, really bad outside of theory.

InitiatorFactoryFactory I do not mourne thee!

Could you please elaborate that? I still see patterns like Builders, Factories, Singletons and even sometimes a Strategy in Java. Why do you think they are bad? What are the functional alternatives?

Java's not a good example as Java 8 took so long to come along. Almost took them 10 years to catch up with the rest.

In modern C# you won't see hide nor hair of Factories, Singletons, etc.

Expect modern Java to be the same in a few years.

Well, what’s about the new HttpClientFactory... https://github.com/aspnet/HttpClientFactory

Yeah, what with the asp.net core team being such great devs, I'll definitely listen to them.

That team can't commit to anything and yet make regular sweeping changes to the framework depending on whatever the current flavour of the month is. This month it's DI, DI, DI.

They've been incredibly inconsistent since ScottGu left.

Singletons have fallen out of favor, not because of language improvements, but because of increased focus on unit testing, which does not work well with singletons. I believe this trend actually started earlier in Java than in .net.

They are not really bad. Reading about them can help you get familiar with how programmers usually name their patterns. But I don't think one needs to study "design patterns" to come up with code using builders, factories, and singletons. People should always know the optimal way to write their code (or almost optimal). They can come up with any design patterns when coding, instead of choosing some among the well-known ones.

In most cases, I think they are a solution waiting for a problem. Let the code grow organically at first and see later if a design pattern helps make it simpler, because we humans are terrible at predicting things, moreso the abstract ones.

But getting lost in a sea of abstraction is easy, it makes you a better architecture astronaut than the one that's sitting on a Tesla now on the orbit listening Bowie's music. Looks good, makes you feel an expert, but really it's almost as bad as selling snake oil.

We programmers, as a whole, should have a code of ethic conduct and a better moral ethos.

It is just the hype cycle...patterns were overhyped for a while some years back, so now it is hip to hate on them. In practice design patterns are just "recurring solutions to common problems" so whether they are good or bad depends the particular pattern and the context where it is used. "Recurring problems" can be all kind of things from limitations of a particular language or platform to universal software design problems, so it is hard to say anything in general.

Some particular patterns have fallen out of favor, like the "Singleton" which is problematic since it is hard to unit test. Instead dependency injection is preferred these days, although DI has its own issues. Some patterns have become so entrenched that some languages have added built-in support for them, which means, I guess, they are not really "patterns" anymore but "idioms".

Other patterns like say the "adapter" or "strategy" patterns are ubiquitous in OO and will be forever, whether you call it a pattern or not.

DPs were over-used by architecture astronauts. For a while I was encountering Factories nested several levels deep, and everybody was making Singleton objects for things that didn't need to be singletons. Ask ten people what a Visitor was and you'd get ten different answers, and there were a bunch of things named Visitor floating around that you needed to read the code of before using, because they were all traps.

I heard of shops that were forbidding code that couldn't be shoehorned into one of the patterns already enshrined within the Gang-of-Four book (even though the book says repeatedly that it is not an exhaustive collection of patterns).

So DPs are bad because, on average, they tend to be an indicator of bad engineering practices, such as cargo-culting and political games. They can be used for good, but if you are considering a position in a pattern-heavy shop it's probably worthwhile doing research into what their engineering org is like.

Are you implying that TDD is bad in practice?

The few times I've attempted to do test-driven development, I've ended up with code that passes the tests, but breaks in every possible way that is not specifically covered by a test.

Well, wouldn't it break in one more way if you don't have a test for it?

No.

The problem is that people all too often see the passing tests and think, "Great, I'm done!". They don't take the time to evaluate whether they have thought of all cases.

That doesn't mean they should not write tests for the cases they _can_ think about.

It's better to have some test cases, rather than no test cases. Even if only the golden path is tested, that's still better than nothing.

Obviously, tests are a good thing and they are an important part of QA. I'm not arguing against automated tests.

I'm merely trying to point out a weakness in the practice of "test driven development", where you write tests before you implement the functionality.

Since you already have tests while you work, it's really easy to just treat them as a checklist, and once all tests pass it feels like you are done.

But in reality, once the feature is done, that's when the hard QA work starts. You need to review the code, make sure you considered all error conditions, check if your assumptions hold throughout the execution of the program, ensure that your code is resilient to unexpected user input, etc.

TDD might be a valuable part of a development/QA workflow, but just introducing TDD on its own is not going to make your product any better.

When your product grows you normally shouldn't have time to evaluate all the cases. That's why you write unit-tests - so you wouldn't need to review all the cases when introducing new functionality. E.g. one of the product I was working on recently is made from several components. Couple components have 100+ unit-tests.

Design patterns are probably broader than just the classic collection of OOP patterns. If you use functional features, new patterns will arise (the most trivial and oldschool one maybe being map/reduce). The original definition wasn't even programming-related, so their scope is quite large.

I don't think being aware of design patterns is a bad idea. In the end, they are just recurring solutions for architectural issues that many developers independently invented to solve them. They just get a bad rep because people applied them even if it wasn't necessary.

If I remember correctly, the original GoF book was inspired by patterns in architecture [1], so it's more about naming patterns they have often seen, and not about "if you use these patterns, your code will be better". It's a glossary of sorts, so developers can use the same words for things. This aim is independent of language and paradigma; the authors just happened to see mostly OOP.

However, just like Asdfbla said: People started to use it as a kind of manual and applied the patterns no matter the problem. Again, the problem is more the people than the idea...

[1] https://en.wikipedia.org/wiki/Pattern_(architecture)

When I had to learn about design patterns at university I basically felt like they were trying to rename things to sound Architecture-ey that already had other names.

I always found myself interested in learning more about design patterns, thinking they'd help me solve problems smarter/faster. But it never seemed to work out – I usually just ended up preferring to write things several different ways and then evaluating the implications of each. And if they happened to be one of the "standard" design patterns, who even cares?

I really enjoyed this talk from Deconstruct 2017: "Patterns Failed. Why? Should We Care?" I recommend giving it a watch: https://www.deconstructconf.com/2017/brian-marick-patterns-f...

I really enjoyed that talk. Thanks for sharing. I usually cringe at design patterns, but hearing the intention behind the idea of design patterns resonated with me. Especially his final point about balancing abstraction.

An addition directed particularly at cofounders: The Freelancer's Survival Guide by Kris Rusch. It is the single best book on entrepreneurship/running a small business I have ever read. It covers pretty much all the bases. It also covers an enormous number of the issues that you will inevitably encounter if you start a business, but likely have never experienced otherwise.

2340 (the mandatory group project course) also covered a lot of this stuff, though not in as much detail.

The suggested reading for that course is a book that blew my mind when I first saw it as an undergrad: Clean Code by Robert Cecil Martin. I believe the examples are all Java, but the lessons are applicable to any language. Stuff like naming your variables more carefully than you name your children.

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

Harry Potter & The Methods of Rationality - I'd to Google to see if that was really even a book.

Just a small pointer because I assume you're a non-native english speaker: you never (I think) contract an auxiliary verb before an unconjugated main verb. You have to write "I had to Google ..." The only reason I mention it is because it's an easy error to make but one that makes people have to read the sentence a few times to figure out what it means. If "to Google" was conjugated, you could write "I'd Googled that last week ..."

Thanks for this, Sophie!! I reiterated this from my GF who also happens to be a professor of English :)

As a native speaker, I've never thought in terms of auxiliary verbs, unconjugated etc, or known what they were. So I'm trying to think of the way native speakers learn, the natural rule.

Doesn't it depend on whether there's a stress/emphasis on the verb? I'd to seems wrong because the had in I had to is stressed, so the had just seems missing. In I'd love to - the would isn't stressed. If it is, like "I would love to, but I can't" then the contraction isn't used. It's how contractions arose in the first place, I guess.

I believe the experience of "stress" that you feel in this sentence is because "had" is being used as a modal verb. That is, it's being used to qualify the verb "to Google" rather than specify it's tense like in "I'd Googled that last week". Modal verbs are a type of auxiliary verb.

I don't know the "real" rule for when you can contract and when you can't, but I'm sure that there's some linguist somewhere who has written a paper on it. The reason that I didn't try to explain the stress that native speakers feel by talking about modal verbs is because I don't think that you can say in general that you never contract a modal verb. For example you can say "I would talk to Jim" or "I'd talk to Jim" where is "would" a modal verb modifying "talk". Maybe it's the case that the only time you have a phrase in the form of [auxiliary verb] [unconjugated verb] is when the auxiliary verb is being used as a modal verb? I don't know. I don't have any expertise in linguistics, I just know the terms because I took a class on it in college.

How is the class actually called?

I believe it was CS 3300 - Intro to Software Engineering

Reply on news.ycombinator.com