Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Absolute truths I unlearned as junior developer

monicalent.com

Post reply on HN
Print view View original

241–250 of 534 posts

Re: Absolute truths I unlearned as junior developer

#241

Post by monocasa »

ghaff wrote: post #183
monocasa wrote: post #179

Earlier 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…

The oil industry is setup as nested subcontractors so that no-one with any money is responsible for these kinds of screwups.

Go look into the actual law, you legally can't call yourself an engineer in Texas without a PE, or a couple tiny carveouts (on the order of you work at NASA, and NASA calls you an engineer)

Re: Absolute truths I unlearned as junior developer

#242

Post by agentultra »

danielscrubs wrote: post #167
pdpi wrote: post #120

Earlier quoted context omitted.

Yeah, I wasn't entirely clear on that bit :) There absolutely is plenty of room for a word more specific than "problem-solver". But our choice of words matters — words carry nuance. In some ways I'd consider "software engineer" as equivalent to "novelist" or "journalist" where "programmer" maps to "writer" and "coder" corresponds to "typist". Software engineer, novelist, journalist all encapsulate a lot of responsibi…

I’ve posted it before. But it gets confusing on the global stage. Software Engineer is a protected title in some countries. In mine it means studied a great amount of advanced math in college, almost nothing else. We usually prefix it with a word that tells if we studied 3 or 5 years. SE in US seems to mean just Software Developer I guess?

In Ontario, Canada you can call yourself a Software Engineer. It's prefixing that title with, Professional that will get you in trouble if you're not licensed with the Professional Engineers of Ontario under the Professional Engineers Act.

Requirements are pretty high: http://www.peo.on.ca/index.php/ci_id/2057/la_id/1.htm

But I suppose industry/capitalism loves the fact that we don't require licensing in order to produce software even if use of said software should be safeguarding health, property, economic interests, etc.

Re: Absolute truths I unlearned as junior developer

#243

Post by gmueckl »

RussianCow wrote: post #85
dahart wrote: post #34

Earlier quoted context omitted.

Oh this is such a good comment! > Legacy code that I wrote myself is hard to read. Sometimes I don’t even recognize me as the author for a while. Realizing I’m reading something I wrote and can’t understand it without studying carefully has been rather surprising and reminds me of the old Kernighan quote “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as…

> Sometimes I don’t even recognize me as the author for a while. This happened to me just yesterday! I was helping a co-worker with a problem, and I noticed some redundant code in the same function, so I told him he could simplify it while he was there. His response was, "...but you wrote that". (And as it turns out, only a few days prior!)

This is why I will point out issues in code only on the form of stating potential improvements as best as I can. I especially try to avoid hating on the author - it might have been me or the boss who's standing nearby...

In fact, I often conciously refrain from using blame on an "interesting" piece of code because it doesn't matter who wrote it. Looking it up would just satisfy idle curiosity, but yield noninsight into how to improve the code. In fact, I think that blame should just list the commits, but hide the authors by default. "What changed? " and "how?" are always much more pressing questions than "who?".

Re: Absolute truths I unlearned as junior developer

#244

Post by oalessandr »

cuddlecake wrote: post #129
SamuelAdams wrote: post #97

> Documentation lies This is a very true statement, especially concerning legacy codebases. I have worked on some projects that have had several developers make changes to it. The original developers were great: they commented every class, had comments for all the methods, and added comments for any complex or funky logic. Then the changes came. And the next developers hacked and slashed the existing code base to mee…

I was thinking about this and because of the book _Clean Code_ I had already decided that comments will lie at some point. So I moved towards descriptive variable and function names, but those could lie as well. So I'm thinking, how could we ensure truthful intentions at all? And I think only a combination of small pull requests, good variable and function names and a thorough review can save us here. But I don't kno…

Types can help. Your code simply won't compile if the types are wrong.

The catch is that you have to define way more types, but if the code is complex enough it's really worth it.

Re: Absolute truths I unlearned as junior developer

#245

Post by PsylentKnight »

BurningFrog wrote: post #105
snazz wrote: post #48

Earlier quoted context omitted.

This is true with basically everything. Game development attracts more than its fair share of truly horrid code, to the point where success seems almost inversely correlated to code quality. If you decompile Terraria (using CIL, which preserves the object design), for instance, you'll notice that its main class is over 40kLOC and that basically all of the business logic is encoded in one great big chain of if-stateme…

Maybe games can get away with more things because when they're done, they're (often) DONE . There is no next release, maintenance, new features etc. Once Balloon Pirates is done it ships, and is never touched again.

Terraria has been getting updates for 8 years now. Maybe that's why it's such a mess.

Re: Absolute truths I unlearned as junior developer

#246

Post by khalilravanna »

docker_up wrote: post #90
mlent wrote: post #78

Earlier quoted context omitted.

Hey! OP here. I definitely don't mean "good enough is good enough" as an excuse -- pushing for quality is extremely important. My point was more about nitpicking line by line for perfection. What you're talking about sounds like a legitimate performance issue. I think we're on the same page, but maybe my point wasn't clear enough. I tried to make it clear in my last point that "code is quality is important" but it's…

When I code review, I differentiate between "code quality" and "opinion". First off, there needs to be a coding standard guideline so that 80% of all issues of "opinion" vs "coding standard" are well defined. This is one of the reasons why I like go, because things like go fmt are the great equalizer. I probably won't like the variable names people chose but I won't comment on that because that's "my opinion". I will…

Another way to skin this cat I'd say is that the definition of "perfection" or "best practices" is different depending on the use-case, company, product, or mission. Making sure you have a very clear definition of quality and "done-ness" is really important here. For some products any bug is a no-go. For others, lots of small visual bugs are ok, and on and on. But once you agree on that definition of quality, I totally agree with you that everyone needs to champion that definition.

Re: Absolute truths I unlearned as junior developer

#247

Post by Retra »

kbenson wrote: post #229
toxik wrote: post #214

Earlier quoted context omitted.

I disagree with this perspective. You of yesteryear is in many ways just another programmer you have to work with; if that makes you cringe, you may be taking a bit too much pride in your work.

> You of yesteryear is in many ways just another programmer you have to work with Taking that idea to the extreme of not having any feeling of ownership or pride (or lack thereof) in your past work seems rather silly to me. It wasn't just some other programmer, it was you . I'm not saying you should cringe because the code is bad , but because you should have a sense of "well, I could have saved myself some trouble o…

Or maybe you cringe at your old 'good' code because you spent too much time on things that ultimately didn't matter.

Re: Absolute truths I unlearned as junior developer

#248

Post by wa1987 »

BurningFrog wrote: post #94
RussianCow wrote: post #80

Earlier quoted context omitted.

This is why I always respond to questions about what I do with "software engineer". I've noticed people seem to perceive "engineering" as more serious than "programming", and it helps to promote the idea that I build things to solve problems and don't just sit there turning designs into code.

I've found myself saying "I, uh, build software" lately. I guess because I don't like any of the established terms.

I tend to avoid the word "building" in the context of describing what I do. After all, the compiler does the building :-) "I design and develop software" is what I usually say.

Would be nice if there was a word that captures the idea of someone both designing and constructing the internals of a machine.

Re: Absolute truths I unlearned as junior developer

#249

Post by taneq »

tomsmeding wrote: post #227
taneq wrote: post #200

Earlier quoted context omitted.

> 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…

> > 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 Your code style can remain exactly the same, and it would still happen. The reason is not that you would write the code differently today, but that you forgot the issues and edge cases that made you write it like that then…

...you don't remember what you were doing 6 months ago? I'm sorry, that's still not a good excuse. Maybe you don't remember every tiny facet but hopefully you'd have a general idea. And above all that, if you're a senior dev then you'd understand that "this code is unfamiliar" does NOT mean "this code is bad."

I mean really, "this code is unfamiliar therefore it's messy therefore we should rewrite it" is a flaming red flag. Chesterton's fence, people!

Re: Absolute truths I unlearned as junior developer

#250

Post by AnimalMuppet »

jayd16 wrote: post #63
lukejduncan wrote: post #11

"Loads of companies and startups have little or no tests" which should scare you, or at least it would scare me if I joined a team. You can definitely over test, but how can you possibly know what you built works (or still works when you change it for the 50th time) if you have no tests? There's a trade-off with testing. Early in the dev cycle, not testing can make you go super fast (supposedly, this hasn't been my p…

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 doesn't reflect the new changes? I fix those tests. Or is it because I broke something? Good to know that early. I fix my code.

Next question: Did my changes do what they needed to do? For that, I write new tests.

Finding your problems early is a big part of agile. Tests are a big part of finding your problems early.

Now: If you're prototyping a new algorithm, would I write detailed unit tests before it gels? Probably not. (In XP, we called this a "spike" - trying to nail something down, not necessarily writing production code.) But even then, how do you know that your algorithm does what you need it to do? Maybe some tests?

Post reply on HN