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

181–190 of 534 posts

Re: Absolute truths I unlearned as junior developer

#181

Post by ghaff »

wbl wrote: post #153
ghaff wrote: post #128

Earlier quoted context omitted.

Engineer is not a "protected term" in any US state that I'm aware of. "Professional Engineer" has a specific licensed meaning but, if I have a degree in mechanical engineering I'm pretty sure I can call myself an engineer anywhere in the US without the licensing police coming after me. (Unless, of course, I imply that I'm licensed when I'm not.)

Not Texas iirc.

As I recall my days in the oil industry, "engineer" was one of the most overused titles. We used to joke about "mud engineers" (reps of the companies that sold the ingredients that made up drilling mud) being, in fact, "mud salesmen." (If you were being generous, they were technicians but they did mostly make recommendations and sell you stuff.)

Re: Absolute truths I unlearned as junior developer

#182

Post by CuriouslyC »

taneq wrote: post #7

The big one for me was the realisation that the code doesn't matter . I mean sure, it does, to us. It's what we do. But really, code doesn't matter. To the end user, what matters is that we solve their problem. We let them do their job, and we make that job as easy as possible. And that's what they pay us for. And to the company we work for, what matters is that we solve the end user's problem, and that we do so in a…

Uh, the code does matter in almost all circumstances. That's because in most cases you're not so much solving something unsolved as providing a lower cost solution via software. The cost of the software (both in terms of initial development and ongoing maintenance) is a factor.

If your problem domain is totally mapped out, maybe any solution that is quick to implement will work. If your problem domain is in any way nebulous or changing, well architected software will save you a lot of money responding to changes, and ongoing maintenance will obviously be cheaper if it's easily testable and robust.

Re: Absolute truths I unlearned as junior developer

#183

Post by ghaff »

monocasa wrote: post #179
ghaff wrote: post #128

Earlier quoted context omitted.

Engineer is not a "protected term" in any US state that I'm aware of. "Professional Engineer" has a specific licensed meaning but, if I have a degree in mechanical engineering I'm pretty sure I can call myself an engineer anywhere in the US without the licensing police coming after me. (Unless, of course, I imply that I'm licensed when I'm not.)

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 now and then. (Yep: https://jobs.dell.com/location/united-states-texas-round-roc...)

[1] https://www.statesman.com/news/20160903/their-name-on-the-li...

Re: Absolute truths I unlearned as junior developer

#184

Post by taneq »

agumonkey wrote: post #14
taneq wrote: post #7

The big one for me was the realisation that the code doesn't matter . I mean sure, it does, to us. It's what we do. But really, code doesn't matter. To the end user, what matters is that we solve their problem. We let them do their job, and we make that job as easy as possible. And that's what they pay us for. And to the company we work for, what matters is that we solve the end user's problem, and that we do so in a…

Then you have technical debt. Wordpress appeared good to end users, but we know how it is underneath and all the problem you get along[0]. It's a fine balance for sure, and forgetting that solving the problem first is what matters is a mistake indeed. [0] about that, there seem to be a 'foot in the door' effect at play. If you get users with a good enough but imperfect product, they won't mind too much if you take re…

> Another instance of worse is better.

I hate this term, because worse isn't better, it's worse. But good enough is good enough and technically-better-but-not-available-yet is worse than adequate-and-available-right-now.

Re: Absolute truths I unlearned as junior developer

#185

Post by [deleted] »

CuriouslyC wrote: post #173
docker_up wrote: post #72

Earlier quoted context omitted.

> Understood as senior: Legacy code that I wrote myself is hard to read. For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code. The younger programmers have routinely told me "commented code means the code isn't very good." I chuckle and ignore them and wait for them to hit their mid-30s and older.

Comments rot, and details about what is going on is better incorporated using good variable names and functions that abstract aspects of a task from their implementation. While I don't like comments that try to explain what code is doing (write better code), comments are very useful for annotating WHY code does what it does. They're also very useful for adding documentation references, code use gotchas and things tha…

[deleted]

Re: Absolute truths I unlearned as junior developer

#186

Post by asdfasdfasdfa »

ramraj07 wrote: post #84
jayd16 wrote: post #63

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

You say you've never understood the benefit of unit tests but you list three really great things: they help you debug stuff while you're writing it, they help you understand what you're writing and the edge cases, and they help others understand your code later. That's all great stuff.

Re: Absolute truths I unlearned as junior developer

#187

Post by snicky »

enobrev wrote: post #170
beat wrote: post #15

Admittedly, my first days as a junior programmer were before some of you were born, but I'm thinking of a particular format here... Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you and assume you're making excuses for your own bugs and lack of understanding. Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and…

> code that I wrote myself is hard to read This has happened more times than it probably should: 1. Arrive upon some code I wrote at some point in the near or distant past. 2. Review it to get some idea of what I was trying to do 3. Laugh at my young self for being so naive 4. Refactor or Rewrite 5. Re-realize the edge-cases and difficulties 6. Remember this being a problem 7. Refactor And Rewrite 8. Either `git rese…

Semi-related story of mine:

1. Stumble upon some specific problem with a web framework we use.

2. Jump straight to stackoverflow.

3. Sbd had a similar issue, nice.

4. Sbd wrote a very concise answer, nice too.

5. There's my nickname under the answer. Oh, wait...

Re: Absolute truths I unlearned as junior developer

#188

Post by ghaff »

nobleach wrote: post #174
ghaff wrote: post #128

Earlier quoted context omitted.

Engineer is not a "protected term" in any US state that I'm aware of. "Professional Engineer" has a specific licensed meaning but, if I have a degree in mechanical engineering I'm pretty sure I can call myself an engineer anywhere in the US without the licensing police coming after me. (Unless, of course, I imply that I'm licensed when I'm not.)

If you work in a music studio, and you call yourself a sound engineer, no one is going to ask to see your credentials because it's assumed that you engineer sound. The same holds through with software engineering. No one expects you to carry some sort of card. When it comes to structural, or civil engineering, there is a far higher expectation that the things you design are not going to fall down. But we're able to u…

>When it comes to structural, or civil engineering, there is a far higher expectation that the things you design are not going to fall down.

The big thing is that you need a P.E. in many cases to do things like sign off on drawings for regulators. Some civil engineers, mechanical engineers, etc. have PE's and many don't. In Louisiana, I had business cards with an engineering title and definitely worked as an engineer. At some point, had I remained in the oil business, I'd have gotten a PE because I'd presumably have eventually been in a position where I had approval authority over designs submitted to various government agencies.

Re: Absolute truths I unlearned as junior developer

#189

Post by chrshawkes »

lmm wrote: post #111
docker_up wrote: post #72

Earlier quoted context omitted.

> Understood as senior: Legacy code that I wrote myself is hard to read. For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code. The younger programmers have routinely told me "commented code means the code isn't very good." I chuckle and ignore them and wait for them to hit their mid-30s and older.

Early 30s here and I've realised that comments are worse than useless most of the time. Nothing enforces that the comment is correct, so a significant proportion of comments will be false, so no comments can be relied upon. Descriptive types, clear tests, and sensible variable names are much more effective strategies for making code understandable. Comments should be a last-resort stopgap.

All those comments of "blah blah blah gets or sets a value" on my class properties, why do we add all that overhead to our projects to the point we have to use tools like GhostDoc to write our worthless comments? This industry is on crack sometimes.

I simply like comments for adding things like... so and so told me to do this... or simply documenting weird behavior or weird business logic.

Re: Absolute truths I unlearned as junior developer

#190

Post by rustyboy »

archagon wrote: post #86
pdpi wrote: post #74

Earlier quoted context omitted.

This is why calling people "coders" annoys the hell out of me. There was a popular blog post a long way back[1] about how you shouldn't call yourself a "programmer" because that builds the expectation that programs are the key output of your work. "Coder" takes this problem even further — your job is no longer to build a program (with all the thought and design work that entails), but rather to type out code. I'm not…

I dunno. I’m a programmer because I like solving problems through code, and I’m not really interested in solving problems outside this toolset. Some artists were exclusively painters, and we still call them that.

To you that's great, the article the parent was referencing is from a marketing perspective. He gives the example of quants, they solve financial problems with code. The same is true with data scientist, they just solve analytical problems with code.

In both of these situations they're a programmer, but they sound cooler and will go a lot farther when applying for jobs or moving up in a company than the person who labels themselves as "a programmer".

Post reply on HN