>I read “that orange website” all the damn time.
Is she talking about HN?
Absolute truths I unlearned as junior developer
91–100 of 534 posts
Re: Absolute truths I unlearned as junior developer
#92One thing the OP mentioned but I think isn't talked about much is that for me everyone has their own style. Some people have great abstractions, others lots of tests, some more code comments, interesting variable name choices, some like functional-style, or lots of frameworks & patterns etc. From our team I can often see who wrote something just from how its written. Now as a junior I just wrote how I liked and hated…
> Then came a long awkward phase where I tried to fit in closely with other people's styles and figure out their intent and design - this is a very difficult way to write code and I wasn't very productive.
My first gig was at a 3 person team, including me. The other two wrote their code in basically identical format. I ended up codifying a linter config to make a style guide that basically all existing code already fit into. I remember thinking, this is never going to be so easy again.
Your post makes me think I was right.
Re: Absolute truths I unlearned as junior developer
#93Earlier quoted context omitted.
Debt (technical and otherwise) is leverage if utilized well, and potentially crippling if abused.
I knew a shop that refused to move its customer data out of an ancient MS Access instance until one day it just started shedding records. That's what I think of when I hear technical debt. What are examples that make sense and don't just explode in your face?
An example of really bad technical debt we made in one of our projects was: back when Facebook apps were a thing, another social networking site released an app platform that was very similar to Facebook. Some companies had early partnership and launched at release, but we weren't aware of it and were caught flat footed.
Our code wasn't built to be generic enough to be able to work on anything but Facebook. So what we did was simple: copy the whole project, change the stuff that didn't work right.
The next time a social networking site released a platform we refactored our main code and introduced the proper abstractions so we could use it on all 3 sites. That code ended up working for most of the other social networks that launched an app platform.
Re: Absolute truths I unlearned as junior developer
#94Earlier 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…
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.
Re: Absolute truths I unlearned as junior developer
#95The 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…
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…
Problem solver can be the title of pretty much any job though.
"I'm a problem solver, I fix problems by diving down and welding broken things at oil platforms"
"I'm a problem solver, I make sure the books are correct at the end of the financial year"
etc. I mean it is correct but if someone calls themselves a coder/programmer/software engineer (even if they are not real engineers) then I know roughly what they are doing each day even if the value they create and what they are working on can be wildly different. Just like a deep sea welder.
Re: Absolute truths I unlearned as junior developer
#96Earlier 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…
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.
From Wikipedia:
Engineers, as practitioners of engineering, are people who invent, design, analyse, build, and test machines, systems, structures and materials to fulfill objectives and requirements while considering the limitations imposed by practicality, regulation, safety, and cost.
If you’re doing that you’re an engineer. Hopefully we are all doing that.
Re: Absolute truths I unlearned as junior developer
#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 meet the new spec. Except they did not update any of the comments, so now what was once true and reliable is now frail and questionable.
Now, whenever I inherit legacy code riddled with comments, the first thing I do is delete all the comments. This helps me focus on what the code is actually doing, rather than what someone thrice-removed said it should be doing.
Re: Absolute truths I unlearned as junior developer
#98> So imagine my surprise when I showed up at my first day on the job at a startup and found no tests at all. No tests in the frontend. No tests in the backend. Just, no tests.
That one hits home. I felt like I was being so helpful when I, fresh-eyed after finishing some entry-level C language book, suggested that we should implement unit tests to the legacy software.
The product lead, to his credit, did not chew me out, but stated very reasonably, "This software is old, relatively stable, and will likely be dead or sunset in five years. It's not worth the man-hours it would take to try retrofitting unit tests onto a piece of software this old, only for the product to be killed six months after we finish writing them."
Re: Absolute truths I unlearned as junior developer
#99The 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…
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…
And on the best of days - involves deleting code.
Re: Absolute truths I unlearned as junior developer
#100Earlier quoted context omitted.
Debt (technical and otherwise) is leverage if utilized well, and potentially crippling if abused.
I knew a shop that refused to move its customer data out of an ancient MS Access instance until one day it just started shedding records. That's what I think of when I hear technical debt. What are examples that make sense and don't just explode in your face?
I'll use your example: I've seen companies start life as Access databases and make plenty of money, and then pay for the proper rewrite out of the revenues generated, instead of doing it the "right way" up front. (when the costs to do it up front may have resulted in a failure to launch)
I don't think it's the type of debt that's the issue, as much as how you manage it.