Don't listen too closely to the issues people have with GoF and Design Patterns. Yes, they have their issues and an over-reliance is an issue. However as a junior engineer you should learn these things and come to this realization (or not) yourself! Also if your company does use these things, code standardization across the org is more important than the downfalls of overly complex patterns.
I read these arguments instead of focusing on learning patterns and it just caused grief until I decided to learn the patterns.
> However as a junior engineer you should learn these things and come to this realization (or not) yourself!
This is such great advice. Wonder if theres even something in there about how learning through experience why something doesn't work being as useful as learning it in the first place.
I do think we throw the baby out with the bath water with many ideas. Despite us learning useful skills subconsciously.
Yes I intend to learn and integrate design patterns and OO programming in general so that I can gain some confidence, and maybe later I can finally understand why my software development professor teachers hated this so much and teached us Haskell and Clojure instead :-)
If you're anything like me, given enough time you wonder if all the 'fluff' of OO is necessary as you seem to be writing code to satisfy the programming style rather than the domain problem. You'll then try FP and find it has its own pitfalls - especially around how complex the code can get if you have a load of smart Haskell engineers - and suddenly they have the same problems ('fluff'). Apparently at some point I'll have a similar move to Lisp and discover how complex the code base can be with multiple engineers (I'm 8 or 9 years into this engineering journey myself!).
My current goal with software is to write this as simply as possible that a junior developer with 6 months experience could read my code and know how to modify it.
Agree with the GP. In a sense even if design patterns are not such a great idea, there's so much code written with those patterns in mind (and classes/variables named accordingly) that it's beneficial to understand at least briefly what the names mean.
(That said, quoting Wikipedia, which I agree with also: "A primary criticism of Design Patterns is that its patterns are simply workarounds for missing features in C++". In particular, these days with more modern languages [and also the modernization of C++] some of the workarounds aren't that important any more)
As for why your professors prefer Haskell and Clojure... for some reason functional programming aligns with the way the stereotypical academia type person thinks. In practice, you should be using the best tool for the task, and learning various aspects of software engineering (as opposed to taking a side) should help you in the long run.
What often happens is you never get to "code standardization across the org" because technology changes too fast. But you still have to deal with overly complex patterns, varying and mis-applied patterns, etc.
Oh I 100% agree but as a junior engineer you're not going to be able to change that, if you can change it you probably won't change it for the better, and using HN comments to fuel debates over long-standing patterns will just cause resentment. These are totally valid opinions to have once you find them out for yourself, IMO.
QA should be writing the underlying code along with the BDD-style tests, using something like a Page Object Model design, with BDD-wrappers on top mostly for non-technical analysts like PMs and BAs to understand coverage and add test cases. I think if you're doing it for anyone else's benefit it falls flat. If it's a no-code solution for QA then it becomes a drag and you should hire an SDET to manage it (and train the other staff to write the underlying code too). If BA/PM is not involved in test design it's a pointless wrapper, I agree. Personally I'm not a fan and spend my time focusing on better reporting so people can see what's tested & if they want an additional case I can just add it myself.
The problem is there are three to 4 veins of QA. SDET (largely automators, tend to scale and manage the automation), analysts, who go over test results and pull out trends, manual testers/non-automators, because nothing brings out the bugs/bad assumptions like putting a non-techie in front of something, and then... well, I'd lump software maintainers/DevOps into it too.
I'm not impressed at all by Gherkin, BDD, or Cucumber. Never once has any business person gone "oooh, let me read the tests!", And in the rare circumstance they do, what you'll find is a secondary grammar develops where particular step implementations gain loaded significance, far and above the natural language implementation of a step, making things complicated.
At this point, I just tell people to keep notes, make checklists, get familiar with the data model for test data authoring, then go eith God, and always put the User first.
Mileage varies greatly, but there's a culture problrm in a lot of places where "the fiture must go out" always takes precedence over "the spec must be right".
And no one ever wants to rip apart testing tools to figure out how they work.
Interesting, we definitely felt it in Menlo Park. Perhaps being on the second floor made it more noticeable? What stood out to me was how long it was — it felt like we were moving for 15-20 seconds, though it could have been shorter.
Actually it’s common for Haskell devs to write property-based tests that are far more complex than regular tests (identifying useful properties is a true artform). Source: I’ve been a test engineer on a large Haskell product!
> and the only thing you need to get a job is good whiteboard/leet coding skills
I have over 8 years experience and don't find this is the case. Maybe it is only for junior roles nowadays? Sure I've been leetcode'd in interviews (and sometimes failed!) but normally it's more conversation driven with a little project and/or code review.
I always assume someone who can build a small production web app from DB Schemas to the front end, including authentication and payments but nothing more specialist than that. Able to jump in anywhere along that stack and be dangerous enough. Probably abstracted via frameworks, so knowing one in-depth front-end and back-end.
Chat to your doctor about this, sounds like it may be ‘proper’ depression and they’ll be able to give you advice to tackle it. Maybe you aren’t but talking it through early and catching it early is best :)
A life lesson I learned was to ensure your personal life is as satisfying as your work life so when one tanks you have the other. Make sure your mental model of yourself is >than just ‘software developer’. Learning Japanese sounds healthy :)
On a productive note, if you want work look at Python. There’s tons of remote Python roles and it has some ML elements your maths knowledge will help with.
I recently started a degree with Open University in Engineering (a distance learning course that's fully accredited in the UK but works for me as I move around while my wife works as a Postdoc, currently in Palo Alto). The book I've found that covers me from math basics (basically GCSE, so high school Maths) through to the more advanced topics I know I will need is Engineering Mathematics by K. A. Stroud. I'd highly recommend it. It contains a good number of exercises (and all solutions), covers all the topics I need, and progresses at a good pace. You can see the contents here: https://www.bloomsbury.com/us/engineering-mathematics-978135...
Honestly I use bash for this. I keep a local repo of .deb/.tar.gz files and scp them onto a machine which makes them reproducible. I use uvt-kvm for VMs, config files to cover basic settings, and that's basically it. I run a fairly decent sized test lab with multiple servers that have to be reproducible, quick to edit, and install fairly complex toolchains.
I read these arguments instead of focusing on learning patterns and it just caused grief until I decided to learn the patterns.