[deleted]
Absolute truths I unlearned as junior developer
381–390 of 534 posts
Re: Absolute truths I unlearned as junior developer
#382Earlier quoted context omitted.
”Prod is on fire and nobody can figure out your burrito pasta” ”Isn’t this a wonderful learning opportunity for all of us” Debugging time is never a good time to start honing new skills.
“Burrito pasta” is a great term! Is that something that you just came up with? It sounds like spaghetti code but even worse because it’s covered with a messy layer of beans and guacamole and wrapped in layers of tortilla.
Just came up with it. The complexity of monads and other post-grad level CS stuff mixed with good old spaghetti code.
Next up: some doofus who learned high-order Haskell in middle school, and takes offense of me calling it complicated.
Re: Absolute truths I unlearned as junior developer
#383Earlier quoted context omitted.
Tests are anti-agile. TDD is waterfall. Legacy tests add friction to making changes. Sometimes you want that friction but in a frenetic prototyping phase its detrimental. This is especially true when business goals are changing constantly (such as early prototyping). How do you know what you built works? The only thing that truly matters is that the user story is satisfied and to that end unit tests are terrible. At…
I still struggle to understand the real benefit of unit tests; the most intuitive tests that test real business logic that I've written always become something like semi-integration tests. Pure unit tests that test a small isolated function are almost never useful to catch bugs after they're written. The only legitimate use for them has been that it's easier to understand the purpose of the function and edge cases. A…
For unit testing, I suggest starting with parsers, or any string-parsing code you have. They tend to be nicely self-contained and have lots of edge cases that you can test in a data-driven way, using a loop.
Even if you're just using a regular expression for parsing, it can be worth moving the parsing code to its own function and testing it like a parser.
Re: Absolute truths I unlearned as junior developer
#384Earlier quoted context omitted.
Tests are anti-agile. TDD is waterfall. Legacy tests add friction to making changes. Sometimes you want that friction but in a frenetic prototyping phase its detrimental. This is especially true when business goals are changing constantly (such as early prototyping). How do you know what you built works? The only thing that truly matters is that the user story is satisfied and to that end unit tests are terrible. At…
> Tests are anti-agile. TDD is waterfall. Legacy tests add friction to making changes. Strongly disagree. Tests empower agile. Here's a module/class/object/file. The unit tests test the externally visible behaviors of that code. Now stuff happens; the code needs to change. That's OK, we're agile, we can deal with it. I make the changes. What did I break? I run the existing tests. Some break. Is that because the test…
Tests might make you personally feel safer making changes but they are not Agile(tm) because they attempt to predict needs instead solving an explicit existing need. They violate YAGNI and worse there is work in removing and rewriting old tests.
Re: Absolute truths I unlearned as junior developer
#385Earlier quoted context omitted.
When seniors (and above) complain about the low quality of junior code, I tell them to go look at their own code from 6 months ago. It's an endemic issue, core to the problem of poor software. > My goals used to be to write code that looked and felt cool to myself and others, ... My goals are now to: - make code so easy to read it’s boring Same for me, and I'm sure same to many of the folks that have advanced past se…
> seniors [...] complain about the low quality of junior code [...] their own code from 6 months ago. What classes as 'senior' that their own coding style has changed that much in 6 months? O.o > I still do write "cool code", for code that I will only use myself that doesn't go into production. But for all others, I write easy-to-read code. Good dev. Remember, you are not your audience. Unless you're just writing pla…
Unknown unknowns.
My coding style hasn't really changed in years - frankly, I don't write a lot of code, I do other things. But I often run into situations where I'm irritated at my own bad code from months earlier, when the shortcomings of the code are actually driven by things I know now that I didn't know then.
Re: Absolute truths I unlearned as junior developer
#386Absolute truths passed on by my various line managers:
- Assumptions are the mother of all fuckups.
- The optimal number of people in an organisation is 3. At 4 you start losing efficiency. At 80,000....
- The more you progress in the hierarchy, the more you realise it is the same idiots at every level.
Re: Absolute truths I unlearned as junior developer
#387Overall a good article, but I completely disagree with the notion that "good enough is good enough". I've been in a lot of code reviews where developers push back because it's "good enough". You need to maintain a defined level of quality otherwise codebases go to shit very, very fast. I was recently told in a code review that a Cassandra read before a write (to ensure there were no duplicates) was "good enough" beca…
I'm going to challenge you here (admittedly without full context, but to make a point). It sounds to me like the problem you're describing requires a database has ACID transactions which is not Cassandra. Therefore Cassandra is a poor choice and in my view that is poor engineering. This being said, I'd err on the side of agreeing with the developer who determined that they are not capable of writing code that guarant…
We aren't in disagreement, and I don't take your comment as a challenge, it was exactly something we went through with this feature. The point is, who gets to decide what "good enough" is? The difference between my "good enough" is a lot different than my coworker's "good enough", and I think that's what separates levels of maturity as a developer.
In fact Cassandra wasn't my first choice, but a strongly consistent database wasn't available to us. As I mentioned in another comment, making the very best decision you can given the constraints of your system is what one should strive for. Not stopping at "good enough" because of (poor) intuition that error conditions "probably won't happen".
We decided to go with LWT and eat the latency costs as a trade off to "stronger" consistency, realizing that Cassandra doesn't offer the same strong consistency as an ACID database. Not perfect, but it fit within our SLA, decreased the probability of encountering duplicate values, and if there was an error, it was easier to detect and the user could be directed to try again, vs having a completely silent error condition that would cause a small percentage of our users tremendous amounts of trouble.
Re: Absolute truths I unlearned as junior developer
#388Earlier quoted context omitted.
Here's what happened to me(A) and a friend(B) from a former workplace of mine(open-source project): B: Take a look at this shit code that I found. A: Whoah, it really is shit. Blame it so that we can see what kind of genious is behind this. B: ... A: Well? B: Apparently you wrote and I reviewed/approved it.
The "who wrote this?" mentality is a trap that's good to avoid. Get comfortable with different ways of writing something that, while they might have different tradeoffs, accomplish the same thing, and try to see past that. Understand that most code wasn't written by anybody--lines 1 and 3 were written by Alice a year ago, line 2 was written by Bob 2 years ago, and line 4 was written by Alice yesterday. `git blame` is…
I’ve always found the svn alias ‘svn praise’ pretty entertaining for this reason.
Re: Absolute truths I unlearned as junior developer
#389Earlier quoted context omitted.
The term "engineer" is definitely protected in Texas, and I think some other states.
Someone ought to tell whoever put all these job listings up (including in Houston): https://www.rigzone.com/a-mud-engineer-jobs/ ADDED: TIL apparently Texas is indeed exceptionally restrictive (in theory) about the use of the term "engineer." [1] I'd be pretty certain this is widely ignored in practice. Leave the oil business aside, I'm guessing that tech companies in Texas probably advertise engineering positions no…
Replying to your edit: there are no jobs on that Dell site in Texas with engineer in the title. It's including some from Minnesota for some reason.
Re: Absolute truths I unlearned as junior developer
#390Earlier quoted context omitted.
> Tests are anti-agile. TDD is waterfall. Legacy tests add friction to making changes. Strongly disagree. Tests empower agile. Here's a module/class/object/file. The unit tests test the externally visible behaviors of that code. Now stuff happens; the code needs to change. That's OK, we're agile, we can deal with it. I make the changes. What did I break? I run the existing tests. Some break. Is that because the test…
Tests might make you personally feel safer making changes but they are not Agile(tm) because they attempt to predict needs instead solving an explicit existing need. They violate YAGNI and worse there is work in removing and rewriting old tests.
I see absolutely nothing in the Agile Manifesto that precludes tests. Nor do I see any basis for saying that tests attempt to predict needs. They are for the future, true, but they're also for the present - as is every line of code you write.