Absolute truths I unlearned as junior developer

https://monicalent.com/blog/2019/06/03/absolute-truths-unlearned-as-junior-developer/

by dcu • 7 years ago

1529 511 7 years ago

What a great article.

Definitely goes under the heading of "Truths So True They Seem Obvious."

As for "Disorganized or messy code isn’t the same as technical debt," I can't look at messy code without automatically cleaning it up. It's automatic as I read and understand. In the last 5 years I've probably checked in hundreds of PR's of cleanup. If this takes anymore time and/or effort on my part I don't notice it. The only thing is someone has to merge it.

hashhar• 7 years ago

I have a rule of thumb to assist with this. If i feel like I have to maintain some state in my mind to understand a particular piece of code then I opt to clean it up since it'll potentially save future developers that time.

yomly• 7 years ago

The thing is, especially with juniors, cleaning up code leads to a few things:

- poorly executed cleanup (aka regressions)

- misunderstanding of requirements (new bugs)

- "standardization" of naming (now you have two standards https://xkcd.com/927/)

- restructuring of code/renaming of abstractions which then adds friction to original authors of code (provided they are still around)

Left unchecked this can all happen, at the expense of feature work, and an unmerged PR resulting in missed deadlines and a frustrated junior. Alas we usually learn best by making mistakes though and I find this one hard to teach for some juniors.

I would argue that a measured tolerance of ugly code (and sometimes bad code) is more important until you learn how to spot and write code that doesn't look wrong.

Two articles I found helpful:

https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

yxhuvud3• 7 years ago

There is the debt that is localized to a singular place, and there is the debt that is all over the place and that is a death by a thousand cuts. The former is easier to fix (and will probably be fixed by some enterprising person, but then second one is the more nefarious one that a lot fewer people actually take the time to do anything about.

arvinsim2• 7 years ago

I also learned that job titles don’t “make” you anything. It’s kind of like, being a CTO with a 5-person team is different than with a 50-person team or a 500-person team. The job and skills required are totally different, even if the title is identical. So just because I had a “senior” job title did not make me a senior engineer at all. Furthermore, hierarchical titles are inherently flawed, and difficult to compare cross-company. I learned it’s important not to fixate on titles, or use them as a form of external validation.

Unfortunately, they do matter in the real world.

dullgiulio• 7 years ago

Well, depends. I know people going from CTO of a small start-up to individual contributor in a bigger company, probably for money.

Titles count a lot inside an organisation, thought.

mariefred• 7 years ago

I used to work with one of those, he traded his title and pay for a work permit in another country

duxup• 7 years ago

They certainly "matter" but I think the point more is that skills, responsibilities, ability from one place to the next with the same title is not a good comparison.

taneq10• 7 years ago

True, but the realisation above is key to understanding how career progression works once you hit your cap. A developer can become a senior developer and then a technical lead and then... what? A manager? You can't really go past technical lead while still staying in the trenches.

So what you need to do is be the tech lead for a team working on a bigger problem. Your job title doesn't have to change as long as you're working on a bigger job.

taneq10• 7 years ago

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 an expedient and economical manner, so that it costs less for us to do so than the customer pays us.

Of course, for us to continue doing this, in the long term, we need to innovate and architect and uphold standards and stay on top of technical debt. And all of that put together is "make the code good". But that's an end to the means, and the customer doesn't care what horrors awake when they click that dialog box button as long as the result they needed pops out at the end.

taeric• 7 years ago

I call this the intrinsic quality of the code. As you say, it isn't that it does not matter at all, just that it is over indexed by many of us.

agumonkey9• 7 years ago

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 responsibility for problems when they arise. Another instance of worse is better.

bumby• 7 years ago

I think part of the problem is that humans are fundamentally present-biased. So low quality code that can avoid a schedule delay today is considered preferable to higher quality code that prevents even larger schedule delays in the future.

rb8083• 7 years ago

Wordpress is a great example. Its the most successful, most love blogging platform and usually user's first choice.

bdcravens2• 7 years ago

Debt (technical and otherwise) is leverage if utilized well, and potentially crippling if abused.

CPLX• 7 years ago

Wordpress is spectacularly useful and successful.

taneq10• 7 years ago

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.

patagonia4• 7 years ago

This bothers me. As code continues to eat the world, this is akin to saying “building codes don’t matter”. That is dangerous. And it isn’t professional.

onion2k2• 7 years ago

Experienced developers know when to spend time making sure code is actually good and when a terrible crufty hack is fine. If you think "All code must be perfect" then you're not a pro yet.

afiori• 7 years ago

"code doesn't matter" is more like "code beauty doesn't matter", in the same way that beautiful foundations for a building do not matter (or are incidental) to its stability.

snazz• 7 years ago

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-statements. However, the game has been extremely popular and successful (and is pretty fast, and looks really pretty).

Somewhere there is a balance, but for business purposes it leans closer to the "working ugly hack" side.

gridlockd2• 7 years ago

all of the business logic is encoded in one great big chain of if-statements

One of the big lies of OO design is that you can manage that kind of complexity better with objects/classes, that you should factor out functionality into tiny pieces, and so on.

Unless you have written (and debugged!) an actual video game, you should spare your judgement.

BurningFrog2• 7 years ago

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.

bspammer• 7 years ago

This is very far outside my realm of expertise but isn't it possible they're running some sort of obfuscation on the binary before releasing? 40k LOC seems unbelievable to me, surely even scrolling around in a text editor would be laggy as hell.

gridlockd2• 7 years ago

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.

If your code quality is bad, you can't do that efficiently. Your developers will hate their jobs and churn like crazy.

And by "bad quality" I don't mean "not unit tested" or "not commented" or "poorly formatted". I'm talking about code that is difficult to reason about, difficult to debug and difficult to refactor or extend. This is hard to quantify or even verbalize. It has to be felt.

chimpburger3• 7 years ago

And the business will feel it eventually. Developers have this magical ability to create invisible time-delayed catastrophes.

chessturk3• 7 years ago

This realization is what has attracted me to the Erlang/Elixir world where fault tolerance > provable correctness.

The end user would rather have an application be frantically logging errors in the background, but be working for their usecase, than a program that is fixated with being correct and refusing to run in the presence of errors.

Obviously quality code still matters, but at least in the business realm "does it do what I expect?" is basically your success/fail state.

pdpi6• 7 years ago

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 a coder, or a programmer. I'm a problem solver, and I tend to specialise in the sort of software infrastructure-y problems that are usually solved through code. If you think of yourself as a problem solver first and foremost, then you'll often realise that the best solution involves zero code.

This ${problem}-solver versus ${solution}-user gets even worse when people go beyond define themselves as technology-du-jour users, doesn't matter if it's Rails, React, blockchains, big data, ML, AI...

1. https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

RussianCow3• 7 years ago

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.

rorykoehler• 7 years ago

You're spot on. Regarding your last point though my interpretation of the blockchain hype was that the problem of the business was that they needed quick and easy money. Blockchain investors solved that.

archagon• 7 years ago

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.

cc81• 7 years ago

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.

avip• 7 years ago

And on the best of days - involves deleting code.

LifeLiverTransp• 7 years ago

machine dompteur ?

beat11• 7 years ago

I often say "That's not programming, that's just typing". (Stole it from someone, can't remember who now.)

beezle• 7 years ago

Back in the ice age we were called 'programmer analyst' or even 'system analyst'

philwelch2• 7 years ago

I totally appreciate this attitude. One of the most important qualities of software development is to solve the customer's problem with as little code as possible. "I am coder and therefore the more code I write, the more productive and valuable I am" is a blinkered mindset.

At the same time, you have to actually describe your profession somehow. Everyone solves problems. Solving problems is definition of productive work. A carpenter solves problems by cutting pieces of wood apart and attaching them together. A bricklayer solves problems by stacking bricks on top of each other, with a bit of mortar in between to smooth them out. A car mechanic solves problems by fixing cars. A surgeon solves problems by cutting people open and fixing their insides. Eventually it turns into a bunch of meaningless MBA platitudes. "We don't 'build houses', we 'deliver solutions' to people's shelter-related problems."

If you go to a good surgeon with a problem that isn't going to be fixed with surgery, the surgeon is going to recommend a different solution and possibly even refer you to a different kind of professional. "Hey, you just need to rest that knee and maybe get some physical therapy. Here's a physical therapist I recommend." People understand that surgeons are smart and will occasionally listen to them, so surgeons can get away with this. More importantly, surgeons understand this. Surgeons don't go around thinking, "man, I need to perform even more surgeries because I'm a surgeon and that's what surgeons do" (or, at least, they shouldn't)--they have a deep appreciation of what surgery is and when it is or is not appropriate.

So I don't mind thinking of myself as a programmer, because I'm a programmer the same way a surgeon is a surgeon. If you come to me with a problem that cannot be solved by programming, I will tell you that, because to do otherwise would be a form of malpractice.

wltprgm4• 7 years ago

this topic never stops, trust me

it's time for you guys to realize this effect from calling yourself "coders"/"programmers"/"problem solvers" are nothing but marketing

It's just to impress those who don't know otherwise

fredmorcos• 7 years ago

I tend to specialise in the sort of software infrastructure-y problems that are usually solved through code.

So basically a coder?

cntlzw• 7 years ago

True. Oh man, I was so angry about that. You read all them books, refactor anything, use that functional programming, but in the end: who cares! A shiny new button gets more attention than you refactoring that SQL statement.

chimpburger3• 7 years ago

If you get away from frontend fluff and work on serious backend systems involving large financial transactions, they will appreciate those more advanced engineering skills and disciplines.

molodec• 7 years ago

The code doesn't matter to the end user. Sure. You can say that about any industry. Engines don't matter as long as you can get from point A to point B and gas is cheap, which it isn't anymore. Healthcare norms don't matter when you are young and healthy. You can get away with this kind of reasoning in the short term. Engineering and almost any industry have rigorous codes and norms you have to follow, but not software engineering. Many software engineers are not engineers, but more like unlicensed plumbers or electricians that can fix the leak, and perhaps throw in a bunch of extension cords to make to hookup some electrician devices. Extension cords may work well for a while because they fix the customer problem, but long term may cause outages and fires. I think Software Engineering as a whole would benefit from more rigor. Of course, there has to be the right balance, as too much rigidity can hinder creativity and productivity, but saying that code doesn't matter is a wrong message.

baq• 7 years ago

After 15 years in the business I think it’s worse than that: code is a liability. It matters - to have as little of it as necessary and not a line more.

solipsism• 7 years ago

Nope. Sometimes it's the right choice to leave something in that your heuristic would lead you to rip out.

Can we stop with these simplistic maxims? Engineering is about tradeoffs and dealing with complexity. Trying to reduce the decision-making process to a single sentence is silly.

fengb• 7 years ago

A corollary to this is: the code should match the problem domain.

If the business problem is complicated, trying to further simplify the code usually makes it awkwardly abstracted and extra brittle. The fix should not be _just_ cleaning up the code, but rather trying to resolve the original usecase.

vmurthy2• 7 years ago

Perfecto! As a programmer turned product manager, I see this first hand every single day. The end user doesn’t care what technology you use as long as it solves their problem(s). My managers don’t care what technology my team uses as long as timelines and budgets are met. I’m astonished and sometimes smile at how my old programmer self wouldn’t understand this basic fact.

world32• 7 years ago

You're right that the end user doesn't care about what technology you use, but do they care about things not working? Do they care that a new feature takes 3 months to develop when it could have taken 1 month if the code had been better architected?

Its funny to see management types dismiss the programmers as being "airy-fairy" when they talk about things like code quality and technology stacks but then they wonder why things get completed on time, why bugs happen, why sites get hacked etc.

Somebody else has mentioned this analogy before in this thread, but if you had a house built would you say the same thing about the structural integrity? "As long as the floor can support me then thats all that matters", "House dwellers don't care what kind of structural beams are used to support the floor they just want it to not collapse". That kind of a mentality is ok for an average person living in a house but you'd you have to be off your rocker to hire a building manager who said that.

lisper• 7 years ago

the code doesn't matter

It does if you want someone other than the person who wrote it to be able to fix bugs and add features.

colechristensen2• 7 years ago

Quality matters.

There is quality in code which you seem to be ignoring, troubling.

There is quality in delivering on time.

There is quality in the end-users' experience.

There is quality in the developers' experience.

There is quality in the investors' experience.

Quality is different than maximizing a metric (earnings per share, on time deliveries, user experience survey score, code coverage)

There is quality in finding the right balance in any situation.

Many many people want to maximize a single metric tacitly expecting everything else to be great, that is a good lesson to unlearn. Switching from one quality target to another is not.

CuriouslyC4• 7 years ago

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.

jdewald• 7 years ago

I think the parent's point (though I could be reading my own thoughts into it), is that the things you mention only matter to the user if it directly affects them. An end user couldn't care less what the maintenance costs are if they aren't passed on to them in some way. If they are, then its completely in the interests of the company to have easy to maintain software. Or if changes are time-sensitive and the company is unable to keep up which change requests. If all that's invisible to "users" (or internal stakeholders), it really doesn't matter how much the boots on the ground hate the software.

But I think also the "code doesn't matter" really means, that ideally there is no (new) code, because there is in fact an existing solution but the person asking for the solution doesn't know it. This is likely more the case with internal stakeholders that ask for something to be built that does X, not realizing that there is readily available software or libraries that does X (or something close to it). So part of our role is to know the landscape of what part of the domain really needs new (potentially bug-ridden code) to be written.

prashnts• 7 years ago

I think I get your point. As someone who doesn’t have any particular specialty (I do webdev, “embedded” devices, image processing, tooling, design, etc.), I always hesitate when someone asks me what I do. I consider the things I can do as tools to get something done.

I interned at a research facility where I had to figured out obscure serial commands for a two axis objective stage, interface microscope camera, and image analysis. Then I wrapped it all in a python library for them to use.

From my mentors perspective however, the goal was “simple”: you find a microorganism swimming under microscope, and keep following it to record its trajectory. Make sure each tick is max 10ms because those little ones move FAST. They didn’t care if I used 4 space indents or 2. They cared about getting pandas dataframe so they could do all the analysis.

I can’t explain this in a word or few, and I still don’t know what to call myself! Am I a developer? I don’t know.

sunandshine• 7 years ago

Am I a developer? I don’t know.

I would say the title "Research Engineer" could fit quite well based on what you describe!

smacktoward• 7 years ago

I would argue it's even worse than that. It's not just that the code doesn't matter, it's that code is a liability, and the more code you create the more problems you create.

Code has to be maintained, or it will eventually fail as other moving parts around it change their interfaces.

Code rots. Platform norms are always changing, so today's fresh new code becomes tomorrow's smelly old code.

Code interacts with other code. As the volume of code increases linearly, the number of these interactions increases exponentially. Eventually the complexity becomes unmanageable and the whole system has to be rebuilt. The more code you add to a system, the faster you hasten its demise.

All of which means that code is a liability, in the balance-sheet sense of the term. Throwing code at a business problem hurts the bottom line. The goal therefore becomes to throw just enough code at the problem to solve it, and not one line more than that.

This is the difference between inexperienced and experienced developers. Inexperienced developers handle code like it's spackle. Experienced ones handle it like it's uranium.

UglyToad• 7 years ago

I'd agree with you here, I'm still a way off seniority but for me the takeaway from the past 5 years is good code is code that can be deleted with minimal work.

All code we write is going to be wrong in some way as a result of our understanding of the problem domain being incomplete so I'd rather see code with an obvious place to put an if statement than a lovingly constructed masterpiece of indirection and abstraction.

Obviously there are basic rules to follow, make it testable, don't mix too many concerns in one place but I see so much bikeshedding and overcomplicated code when it just needs to not be obviously wrong and easy to replace when needed.

drbojingle3• 7 years ago

I agree with you but I can't bear to say code doesn't matter. Try not writing any and see how valuable software is without it. Better yet, delete it and see what happens :D. I expect Codeless will become a thing one day but, until that day comes you will write code, because the code is necessary and I have trouble saying that the code is needed but also doesn't matter. Least important necessity maybe?

neetodavid• 7 years ago

I've read on this website about people launching minimum viable products that appear to the customer to be some kind of automated service that in reality are the owner manually satisfying the order.

The software isn't necessarily what the customer values. You can provide a valuable service with 0 LOC

seer• 7 years ago

Hah I got the exact opposite realization actually.

Yes if you boil it down to it’s essentials you are right the customer is the one with the money, so satisfying his needs/desires is what matters.

But, and thats a big but, we as devs are also humans, we also have desires and needs, and in the long run companies that successfully balance the needs of its users with the needs of its workforce get the best workers, which solve the problems of their users better/cheaper/faster.

So it’s more of an equilibrium kinda thing. If you stray too much in any direction the organization tanks - either the users loose faith, or the people satisfying theirs needs do, which leads to failure just as much.

The complexity with balancing this usually stems from the fact that both of those variables are subjective to their respective environment - users can tolerate bad solutions if there are no alternatives available, same with devs.

And that is also a subject to information availability - devs can be ok with their situation because they don’t know what salaries are at that other place for example.

z5h• 7 years ago

Thoughtful and deserving of HN front page attention.

lukejduncan2• 7 years ago

"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 personal experience but in general it seems to be true for teams). But you'll plateau quickly and then at iteration 1+n you'll just come to a screeching halt because you introduce bugs or the new engineer isn't confident that they didn't break downstream things and needs to manually test everything. Testing early will cause you to go slower earlier (again, not my personal experience but seems to be generally true of teams) but you'll be significantly faster at iteration 1+n.

I usually summarize this as: testing early will on average make your development faster over the life of your codebase. Knowing this you can make trade-offs. Not testing early is probably better called prototyping. It's OK to prototype in production if you need to. But know what you're getting yourself into.

codeulike• 7 years ago

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?

Because software development did exist before the invention of JUnit et al. The old fashioned way is 'user acceptance tests' and of course thats not perfect but its easily understandable, and nearly anyone can sit there and do it. And they might miss things or whatever yadda yadda but at the end of the day in an environment where everyone is short of time and time is money a bit of user testing can often be 'good enough'.

lukejduncan2• 7 years ago

I’m not saying you need 100% code coverage, or 80%. Just some level of deliberate automation. In my personal experience, user testing as your only or primary form of testing gets painful fast.

arvinsim2• 7 years ago

There are some programs that are not designed to last. It doesn't make sense to put in time in that regard.

noobiemcfoob• 7 years ago

A workflow using the code is a itself a type of test. If something breaks, the users will tell you. A lot of code ends up in that space because it was never asked for as an actual project, but now a team relies on it but no developer can be officially assigned to it.

colpabar• 7 years ago

"I don't always test my code, but when I do, I do it in production."

scarface74• 7 years ago

You are making the assumption that most people care about n+1 where the code gets so bad it’s hard to maintain.

- the average tenure for a software developer at a company is 1.5 - 3 years, by the time things get that bad, its someone else’s problem.

- the business folks at a startup just care about throwing something together long enough to get their next round of funding or the exit.

- no one gets promoted by having code that is easy to maintain over the long term. They get promoted by releasing the new and shiny - not maintenance work. See Google.

jayd163• 7 years ago

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 best you could make some integration tests but that is not the same thing.

I also think there are better practices than tests to keep iteration pain low but that doesn't preclude tests so I guess that's not an argument against them. That said I prefer to focus on making composable, low side effect code than write more tests.

Personally I hate tests although I come from games where you need human QA testers to test that your game feels fun anyway so I do admit that's a unique situation.

ramraj07• 7 years ago

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. At times it makes me think about edge cases and identify bugs WHIlE writing the tests, but once they're written, they're never useful unless someones actively trying to understand that exact unit of code.

AnimalMuppet4• 7 years ago

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?

jiveturkey4• 7 years ago

you have a lot to unlearn, young padawan. you must first forget what you know ...

silveroriole• 7 years ago

Having lived through the screeching halt, I agree. There reaches a point where you genuinely cannot make a change without breaking something on the live system, or taking five times as long as is reasonable. You no longer have any idea what the real behaviour of the system or why (doco is NEVER up to date). Not having tests was part of the reason I changed jobs.

I don’t know why people assume that tests hold you back from changes. If they do, they were just bad tests which were testing implementation details rather than businsss logic. That’s an argument to not write useless/stupid tests, not an argument to not write any tests at all. It just seems to be far more difficult for developers to decide what a good test should look like than to decide what any other good code should look like.

wanttocommentt• 7 years ago

good article, I agree with most of the things. However code reviews that only have comments about code style are kinda useless in my opinion. I rather get 50 comments about how to improve my code instead of missed formatting. (which can be also done automatically)

celestialjeu• 7 years ago

That is the exact point the article is making. When you are junior you think that code style is the most important thing but it isn't. (Also it can be handled automatically as you say)

beat11• 7 years ago

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 will tell them to go figure out what's wrong with their code.

Learned as junior: Legacy code is hard to read.

Understood as senior: Legacy code that I wrote myself is hard to read.

Learned as junior: Technical skills matter most.

Understood as senior: Communication skills matter most.

Learned as junior: New tech solves old problems.

Understood as senior: New tech creates new problems.

agumonkey9• 7 years ago

Understood as senior: Communication skills matter most.

can you give examples ?

halfmatthalfcat• 7 years ago

Articulating requirements or architecture to either stakeholders or juniors is key to being able to actually do your job as a senior (whether that's coding yourself, code reviews, planning, interviews, etc etc).

Kalium• 7 years ago

I once worked with a brilliant engineer. He was from Hong Kong. He struggled to express his ideas in English. We tended to let him show us in code instead.

Sometimes this worked. Sometimes it really, really didn't. It also meant we had a very difficult time discussing larger architectural questions with him or giving him useful feedback on his code.

dahart2• 7 years ago

I can try.

Teaching juniors can be more productive than coding. Being 10x by yourself is less good than 3x-ing a whole team. Even better, teach everyone to be as fast & good as you. Good teaching requires good communication and building trust.

Understanding priorities and goals is absolutely critical to making good choices while programming. Writing good code under reasonable deadlines in an organization necessarily involves a lot of discussion about what constitutes an acceptable solution, what doesn’t, how long it might take, how long is too long, what features are nice but not necessary.

Over-engineering, for example, is extremely common, and is caused in part by not correctly balancing goals and priorities with time budgets. It’s usually a symptom of mis-communication.

Can’t even count how many times I’ve seen a programmer go off the rails building stuff that wasn’t asked for, only to have a meeting several weeks later that invalidated weeks of work when the goals were clarified. (That includes me, btw.)

Making large changes and leading a group of programmers often requires a lot of convincing and rallying work along with the technical planning, sometimes much more than you’d expect. It also requires the ability to put yourself aside and allow others to contribute to the design, even when you think your technical solution is superior.

Getting promoted is, in my experience, most commonly a process of demonstrating to others that you listen well, organize well, work well with others, get things done under deadlines, understand and report what juniors are doing to management, budget well, internalize the organizational goals and contribute meaningfully to meeting those goals.

In short, it’s because teamwork is important.

fendy30022• 7 years ago

It's mainly used when discussing task and making architectural / design decision. Junior usually talk in techincal / implementation terms. While senior usually talk in broader / general / business term.

Moreover junior usually have hard time expressing techincal problem.

yxhuvud3• 7 years ago

If nothing else, it is a godsend when talking to PMs. A junior may be like "this code sucks, it is too complex!!" where a more senior can be more like "This code is not written in a good way. If we had some time to rewrite these particular parts, we could provide these features to the users".

Being able to couple value to what you do, or for that matter, to what might not be worth pursuing, is a very good skill. And be sure to not often say no to a PM asking for a feature, but rather give an alternative "doing that is quite complex and might take us half a year. How about we do this other thing that gets us 90% of the way there, but only take a week to implement?"

slezakattack• 7 years ago

There's no hard-and-fast rule on this but generally junior projects are isolated where you may only have one stakeholder. Growing into a more senior role, your actions generally have greater breadth that affect more teams/clients/orgs. Technical chops are worthy but I can guarantee that your stakeholders would rather have amazing communication for things like progress, deployment, etc. than how efficient or beautifully written the project is.

dahart2• 7 years ago

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 you can be when you write it, how will you ever debug it?”

My goals used to be to write code that looked and felt cool to myself and others, to add features in clever ways with as little change to the function signatures and structure as possible so as to not disturb the architecture. While keeping changes small is a good goal to balance, it’s always possible to be too small and add unnamed concepts and fail to restructure around new concepts when you should. Do that a few times in a row (which I have done) and you end up with architectural spaghetti code that might look clean and modular at first glance but becomes a maintenance nightmare. My goals are now to: - make code so easy to read it’s boring, because if it looks interesting, it’s probably too clever - and to identify and name all the unnamed concepts and refactor often to accommodate new features.

RussianCow3• 7 years ago

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!)

jiveturkey4• 7 years ago

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 senior level. The problem of other people, other senior people, needing to read, understand, and significantly modify your code is one of the reasons why you can't really advance past senior in a startup. There aren't enough experienced folks that you have to write "up to". Of course the other part of being post-senior is the ability to scale your expertise, but now I'm digressing quite far. Then once you're that advanced, you don't want to take a pay and scope cut to work at a startup. This is a major contributor to startup technical debt accumulation, one that can't readily be solved.

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. And I review code with that in mind. When comments have a typo that alter the meaning of the comment, I insist that be fixed. Juniors hate me for being too picky. (and I hate them for being too sloppy.)

Remember, the most important part of your job as senior+ is not what you do yourself, it's how you guide others.

enriquto2• 7 years ago

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 you can be when you write it, how will you ever debug it?”

This quote can be interpreted in an intelligence-positive way, to encourage you to learn by writing the cleverest possible code. Then, when you get to debug it, you will be forced to improve your skills. This interpretation is called Kernighan's lever [1] and it is very beautiful. The alternative is a life of boredom where you don't learn anything new.

[1] https://www.linusakesson.net/programming/kernighans-lever/in...

leibnitz27• 7 years ago

Way back in the day, my boss made a lovely observation - 'write your code like it's going to be maintained by an axe murderer who has your home address, and nothing to lose.'

Simple guidelines to live your life by ;)

forgone• 7 years ago

Did he call it "his" observation? I am yet to find a likeable person quoting this.

kps2• 7 years ago

Attribution: “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” — John F Woods, 1991 in comp.lang.c++¹

(I do not know who first replied, ‘I do know where I live.’)

¹ https://groups.google.com/forum/#!msg/comp.lang.c++/rYCO5yn4...

GordonS• 7 years ago

Understood as senior: Legacy code that I wrote myself is hard to read.

Ha, yes, I occasionally come across code I wrote years before and have a few "WTF moments"!

dotnetdemon• 7 years ago

I always find myself saying “Who is the shithead who wrote... oh...”

docker_up5• 7 years ago

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.

lmm8• 7 years ago

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.

crankylinuxuser2• 7 years ago

Thats also a reason I will include as a comment the unoptimized code with comments whenever I do optimized crazycode.

That way, I can understand what is actually being done. And I can then re-analyze why I did the shortcuts to get to optimization.

But 99% of the time, we dont need to optimize. CPU/RAM is cheap. But those 1% of the times when you're going from N^2 to N^logN ... Welll.....

CuriouslyC4• 7 years ago

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 that need to be addressed in the future.

drbojingle3• 7 years ago

There's truth to both sides. Depends on the comment really.

``` doesAThing() //does a thing ```

doesn't help anyone.

My rule: Code is for how, comment is for why.

ben509• 7 years ago

Also related:

Understood as senior: Communication skills matter most.

The reason people dismiss comments is usually that they or others around them aren't good at writing useful comments.

Especially when there are linter rules requiring comments you'll have something like def open_thing(x, y): and a comment, "defines a function that opens thing."

Yes, those are pointless. Often what's going on is a person is dumping their stream of consciousness into the comment field.

It takes practice to understand what a reader needs to know. You have to actually practice reading comments and thinking things through (another reason code review is important in your team) to get good at undertanding what you should write down.

All that said, if you truly hate commenting, at least build a habit of descriptive naming and exploiting your type system as fully as possible.

mbreese• 7 years ago

For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code.

I couldn't agree more.

A while back I got in the habit of trying to write code for "me, six-months from now". So, if I think I can explain it to "future me", then I'm happy. Ever since I started doing that, I've been much happier with "past me"'s code.

In addition to comments (particularly around hard to grok code), I've also started trying to be as consistent as possible in code structure and naming schemes. This also helps a lot.

jschwartzi• 7 years ago

Yeah, whoever told you that has never had the sinking feeling of digging in to a 300 or 1000 LOC function with a pretty refactor in mind only to see just how much of the system relies on that one function. It's really only an issue if you try to be diligent about testing the work you produce, in which case that little refactor could cost your team a week or a month of additional testing while they verify that you didn't break anything.

Or you could sneak one more little if statement or some copy/paste in there to fix it instead, and add a little comment that says "If you modify this line, please verify that your change doesn't impact Line XXX of file FFFF as well." And then you're done in less than a day and have saved a huge amount of testing.

darepublic• 7 years ago

As I've matured as a developer I generally find it easier to read and understand code, whether it be my own or others. As a junior this is something I definitely struggled with.

robomartin• 7 years ago

All excellent points. I got used to filling my code with comments in the spirit of having a conversation with someone to whom I am explaining how an why. Thirty years later I can look at any of my code and quickly understand it. In sharp contrast to this I find most open source code to be difficult and laborious to understand due to the almost total lack of useful comments.

JustSomeNobody3• 7 years ago

Learned as junior: New tech solves old problems.
Understood as senior: New tech creates new problems.

This is one all the people who push "new and shiny" need to learn.

giancarlostoro• 7 years ago

I mean, yes and no, sometimes an old systems so bad it really needed to be killed off and replaced. Or would you rather everyone stick to coding in VB6? I rather we all use C# instead of VB6 ;) I'm not implying we only ever use C#, I know there's other languages, just illustrating a shift in the MS windows development ecosystem that was for the better.

kps2• 7 years ago

Lemma:

Learned as junior: Legacy code is hard to read. Understood as senior: Legacy code that I wrote myself is hard to read.

Lemma:

Learned as junior: Technical skills matter most. Understood as senior: Communication skills matter most.

Theorem:

Communication needs to target the people of the future.

beat11• 7 years ago

Outstanding observation, thank you!

LordHumungous• 7 years ago

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.

Similarly, one thing I learned is that if I find a bug with an OS or platform, 9 times out of 10 it's actually due to some problem in my code or my own lack of understanding :)

loco5niner• 7 years ago

Can suggest it's more like 999 times out of 1000?

enobrev• 7 years ago

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 reset --hard HEAD` or end up with a similar solution, but with better comments

Once in a while, I end up with a [simpler | faster | clearer | otherwise better] version, which makes this process worth while - even with the false positives.

snicky• 7 years ago

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

jjeaff• 7 years ago

I usually do this same thing. But not before mentally cursing out the programmer that wrote this poorly documented spaghetti code... After which I realize it was me.

Sharlin2• 7 years ago

This is probably the primary actual use case for comments. Explain why something is done the way it is; to justify to those who come after why Chesterton's Fence [1] should apply in this case.

[1] https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence

mgolawala• 7 years ago

The best feeling for me is when I come across old code and then re-write it to make it [simpler | faster | clearer | better] .. It is tangible proof to me that I have improved in my craft.

Tade0• 7 years ago

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.

SkyMarshal2• 7 years ago

but with better comments

Communication, especially with your future self, is an important skill.

polyterative2• 7 years ago

git reset --hard HEAD

story of my life

glaurung_• 7 years ago

This isn't quite the same situation but it reminds me a little bit of xkcd.com/1421

munchbunny2• 7 years ago

These days my rule of thumb is to not try to rewrite or generalize until I or my team has tried to do more or less the same thing three times. Before that, you just don't have a good feel for what is generalizable/edge case or what is invariant/variable in the problem space.

I've definitely run into this phenomenon of independently landing on the same design twice because of the same edge cases. At some point back in 2005 or so, I was working on a collision detection component for a physics engine. This was 1-2 years before the Box2D engine, so there was a significant lack of any open source options, so I was rolling my own stuff that was quite similar to Box2D (but Box2D was written much better).

One year later, I came back, looked at the code, thought "this is unreadable!" refactored it, and sure enough, stuff was falling through floors. I went back to my old code, found several comments discussing edge cases having to do with discrete time step problems, and concluded that my old code was in fact the right approach, it just didn't put comments about edge cases high enough in the call stack.

bitL• 7 years ago

code that I wrote myself is hard to read

1. Found some extremely cool code, marveled how amazing it works

2. Realized I wrote it as a teenager

3. Got depressed, questioning my life decisions

logicallee• 7 years ago

As a technique against this, at the point that you're writing the code to begin with, have you ever tried documenting the reasons you're doing something even if it's blatantly obvious at the time?

   // rather than use the API we parse a scrape here with a
   // regex because we signed up and it doesn't have half the fields we want.

like, totally obvious. except six years later when the regex stops matching, and you are already using the API all over the code anyway and you get to this part with the scrape and you don't get it. Are we trying to elude the API requests number limit? or what is the reason for this bizarre scrape.

a lot of people would refactor by seeing if they can put the API call in there, but this wastes massive time you could avoid if you knew the reason for this in the first place. and maybe the API still doesn't have it, and so you put the API call in, you try to remember the reason for the scrape, and then you realize that all this is still the best way to do this, you just have to update the regex to continue to match. work that could have been saved by a simple comment telling you the reason it looks this way.

hyperpallium2• 7 years ago

Code twice: once to understand, once to solve.

As in "42", the first bit is more difficult.

decisiveness• 7 years ago

And each time this happens, you get better about writing readable comments up front describing edge cases and difficulties so that future self can avoid steps 1 - 6 with a head start on refactor ideas / feasibility.

sbmthakur• 7 years ago

Re-realize the edge-cases and difficulties

I think comments can help avoid such scenarios.

taneq10• 7 years ago

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.

My mum told me "if you think you found a bug in the compiler or OS... you're wrong". This advice applies until you're good enough to know it doesn't. She was right.

yakshaving_jgt• 7 years ago

I wish my mother knew what a compiler was.

beat11• 7 years ago

One of the first rules from the book The Pragmatic Programmer is "SELECT isn't broken". (It might even be the first rule.)

kbenson3• 7 years ago

Understood as senior: Legacy code that I wrote myself is hard to read.

As it should be. If your code from a five to ten years ago doesn't make you cringe at least a little bit, the right way to view that is not that you were doing a good job back then, but that you haven't gotten any better since then.

toxik• 7 years ago

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.

fendy30022• 7 years ago

It isn't as simple as better skilled or not. Many times having more understanding about the problem may open your eyes to better / simpler design, or you now don't have any rushing matter that fuel bad design in the past.

Scarblac• 7 years ago

There are absolutely things I was better at back then, mostly because then I spent all my time doing nothing but programming and now a lot of time goes to other activities (meetings, planning, writing, etc).

alkonaut• 7 years ago

New tech solves your existing problems and creates new ones. I have a big pile of problems I have had for many years that I’d love to trade for some new ones. I’m happy to fix one problem and get 5 new ones. I’m happy to get rid of an easy problem and get a new much harder problem. The important thing is that I get some new problems, and nothing will do that like new tech.

Gibbon13• 7 years ago

Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and will tell them to go figure out what's wrong with their code.

Me: 'Even a blind squirrel finds a nut once in a while'

cja23• 7 years ago

Horses, not zebras. But yes, there are a few zebras in the world also.

bpyne• 7 years ago

"Understood as senior: Legacy code that I wrote myself is hard to read."

Your comment came at the perfect time. I just finished debugging a "high urgency" problem with a program I developed and maintained for the past 10 years.

The program started simple with a small list of rules to apply against data sets. Over time the list became a tree of rules that expanded in both breadth and depth. It was refactored once to get the design in line with the rules of the time.

The "high urgency" issue turned out to be the program working correctly. But, the functional user wasn't able to keep in mind some of the rules he set. It took me a half hour, with lots of "why did I do that", to explain it again to the user.

jshowa3• 7 years ago

Things I've learned: I'll never be a senior programmer.

justbaker• 7 years ago

Understood as senior: Communication skills matter most.

I can't speak enough on this one. In our craft, The better one is at communication skills, the more effective their technical skills will be.

kenhwang2• 7 years ago

There's also a strong correlation between strong communication skills and strong technical skills in our industry that demands frequent learning of new skills. So not only does strong communication augment technical skills, it also signals its strength which is also valuable to software developers.

chadash2• 7 years ago

Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and will tell them to go figure out what's wrong with their code.

My first job was in finance and I remember one time that I had a glitch on a complicated Excel spreadsheet. I checked it over, checked again and checked again until I finally concluded that the bug was in Excel itself. So I go to my boss and tell him that the data isn't ready because there's a bug in Excel. I was laughed at by the entire team. They agreed to give me $1000 right then and there if it was really a bug, but if not, I had to admit the shame. Well... of course it wasn't a bug in Excel, I just made a careless, albeit hard-to-find, mistake.

Lesson learned. If millions of people use something, that doesn't mean it doesn't have bugs. But it does mean that you probably aren't going to find those bugs unless you are doing something strange.

oddly, I did once find an actual bug with indexes in Postgres. Because of my earlier experience, I spent a lot of time assuming it was me before I finally isolated it as being a bug with postgres itself. I submitted a bug report and it was patched within a day. But still, 99% of the time, it's me.

xmprt• 7 years ago

You can't tease us like that without explaining what the "bug" in Excel was.

beat11• 7 years ago

I actually found an OS bug in AIX on my first real I-designed-this code project. Worse, the bug was discovered only when the code went into production - it behaved differently on the test servers than on the production servers! The bug caused mmap() system calls to randomly overwrite certain pages in memory with NULLs. Yeah, that was fun. And it was caused by the order in which patches had been applied, which was why it behaved differently in production than in dev/test.

If some second year programmer told me that nonsense, I'd make them go back and either find their bug, or write a test program that exercised the bug in isolation (which was what I did).

HeyLaughingBoy3• 7 years ago

It's unusual, but it does happen. My example is actually from hardware.

I was writing a Windows NT (what's that?) device driver for a communications board we developed for one of our products. I kept running into a problem and struggled with it for days. I was experienced enough to understand that the error was probably mine and the problem was so basic that if it was in the chip pretty much everyone who tried to use it in that mode would be screaming about it not working. The chip was an 8-channel UART (serial converter) and IIRC, the bug was in one of the FIFO interrupt modes.

Finally I gave up, got the phone number for the chip vendor's (I think it was Texas Instruments) local Field Applications Engineer and explained the problem to him. "Oh, yeah, we know about that bug, there's a new version of the chip about to be released. You guys are actually only the second customer to sample that chip. Lucky we found the problem before it went into production!"

kenhwang2• 7 years ago

I just say, even if it's a bug, there's no guarantee it'll be fixed on a timeline that's agreeable to our deadlines. Find a workaround.

koala_man3• 7 years ago

Junior programmers find an amazing amount of system-level issues.

One noob came to me with a serious codegen bug in GCC, where even with `-O0` it would fail to correctly run a trivial for loop. Another found a huge security hole in `sudo` that gave everyone unrestricted access. My favorite was one who asked if the JDK standard library had any known bugs processing the letter "g".

They all turned out to be user error, if you can believe it.

bunderbunder• 7 years ago

Understood as senior: New tech creates new problems.

Related: There are no new problems.

SkyMarshal2• 7 years ago

Learned as junior: Technical skills matter most.
Understood as senior: Communication skills matter most.

I see this often, but it needs to be said with a caveat - the second line presupposes the first. Without the first, the second doesn't really matter (or it does but you're in the wrong career).

retiredcoder3• 7 years ago

Actually it is very disfuncional for me to be in a company that communication skills are ahead of technical.

TheAceOfHearts• 7 years ago

Sometimes you encounter some questionable code and you wonder: "What idiot wrote this?" So you `git blame` and you find out "Oh, I'm that idiot."

retiredcoder3• 7 years ago

I have been in this situation and tried to remember what was going on while I wrote the questionable code. It frequently came down to a day full of interruptions and context switching. Also motivation plays a tremendous role, I know that whenever I have to work on a code base I don’t understand and don’t want to have anything to do with it long term, it ruins my ability to focus.

whatever_dude• 7 years ago

Understood as senior: Communication skills matter most.

I've been of a similar opinion at some point, but now that I see people _optimizing for communication_ as juniors in lieu of actual technical skills, I say: both matter a ton. I hate dealing with a junior that is an extremely good people person but a terrible developer: they tend to think they got everything covered just because people like them so much, even when their actual solutions are terrible.

philwelch2• 7 years ago

Learned as junior: New tech solves old problems.
Understood as senior: New tech creates new problems.

Yep! When you use "new tech", you're making a bet, and not all bets pay off. If you're cautious, you'll hold off until new tech is proven (or pilot it cautiously before migrating). If you're possessed with good judgment, you'll be discriminating in which new techs you adopt. If you have both virtues, you may even gain a competitive advantage.

bsder• 7 years ago

Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and will tell them to go figure out what's wrong with their code.

And, yet, it does happen. The important part as the senior guy is to make the junior guy create a test case and then cut it to the bone until it is obvious where the bug is.

Story time: It's mid ninteen-ninety-mumble and your intrepid hero is a junior programmer handling multi-site integration and testing tool infrastructure. This being the time when the Swiss Army Chainsaw(tm) (aka Perl 4) is well and truly entrenched in the sysadmin and toolsmith programmers, my technical superiors throw me a couple of Perl books, set my deliverable date impossibly soon, and tell me to get going post haste.

So, I code. It's not a lot of code, but it is parsing and matching files in 3 different formats from 3 different sites. Of course, I hear what you are saying: "Perl and parsing is like mixing ammonia and chlorine--and probably more painful." Yes, I concur. But, it is the tool at hand in the long forgotten mists of time when RAM was expensive and spinning rust still resembled an iron brick. So, off I go with regexes for parsing (Yes, I know, now I have 3 problems).

And everything worked quite swimmingly. Except for a bit of idiocy that nobody could track down that occasionally flagged a couple of records as mismatched when manual inspection showed they really were not. Nobody minded that much as the scripts got 99.99% of the job done and didn't give a false negative, so: "Ship it, junior."

And so we did.

However, the bug annoyed me because I had to got clean up the false positives when they fired. And, if I am anything, I am a VERY lazy programmer--and this was preventing me from being lazy.

So, I eventually am waiting for one of the other groups to deliver, and I go spelunking for a testcase.

Spelunking? HAH! Cave diving is a better analogy.

The program took the most inclusive of the syntaxes, used each record from that to build a regex to look for the corresponding record in the other syntaxes, matched what it could and flagged what remained.

So, the program was building a dynamic regex on-the-fly and then using it. Not a huge deal, but the regexes were larger than most people were probably comfortable with. No problem, I validated this on much smaller records out to REALLY big records, and they work well.

Except for those weird cases ...

So, I'm looking through a case that works and trying to compare it to a case that doesn't. And I accidentally fat-finger some character set match and delete a character that shouldn't matter.

And the regex fails ... provoking the Asimovean "That's funny ..."

So I delete another character ... and it works again. What?!?!?!

So, I add a character. And it fails. And I add another. And it works again.

I stared at that regex for what felt like EONS until the light bulb went on.

The one that worked? 511 characters or 513 characters. The one that failed? 512 characters.

So, yes, I, a total Perl n00b managed to find a bug in Perl 4 in my first ever Perl program.

Sometimes the junior dude gets really unlucky and finds an actual system-level bug.

jv22222• 7 years ago

Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you

Same thing happens in reverse! ;)

A few years back I told 3 devs who reported to me that there was a bug in Laravel database sub system.

The bug was: If you use the word "returning" in any Laravel insert query the system would crash (Laravel 3 & 4).

None of my guys would believe me!

I finally tracked the bug down to

laravel/database/connection.php
public function query($sql, $bindings = array()) { ... etc ... elseif (stripos($sql, 'insert') === 0 and stripos($sql, 'returning') !== false)

I sent an email to the Laravel team and never got a response... but the bug stopped happening some time after that ;)

I think it was relate to mySQL version as well.

gastlee_za• 7 years ago

We’re so far behind everyone else (AKA “tech FOMO”)

This one hit strongly for me because I didn't realize it until reading this...

I am sure our CTO and PM are tired of me pushing for the latest tech I read about on here all the time. I will hold back a little more from now on.

jasonhansel• 7 years ago

I think another truth to unlearn is "users know what they want, and can express what they want in precise technical terms."

cuddlecake2• 7 years ago

And the complementary truth would be "I know what the user wants".

My team and I are kind of trying to break this up, since we suffer from this a lot.

tmaly• 7 years ago

I believe more in tests and documentation now more than ever.

When you have to support legacy code with no docs, no specs, no tests, you change your mind pretty about the value of tests and a good specification.

As a senior engineering manager, I push hard to get good requirements for my team. Its being a sales person with the business side.

airnomad2• 7 years ago

Developers are new factory workers. Pay is good now because industry is expanding and there's not enough of us but it won't be like that forever. And bottom line work is already being commoditized (WordPress ecosystem etc).

ThirdFoundation• 7 years ago

Finance, accounting, engineering, and many other careers have been around longer, have been commoditized to varying degrees, yet still enjoy good pay.

I think developers will still make good money for decades. I could, however, see an issue with junior developers finding less opportunities in the coming decade. I think there will be less need for juniors and the entry level jobs will be harder to come by. Some of those skills are more easily "commoditized."

bluejellybean2• 7 years ago

From a hiring perspective, the problem is, and will continue to be, the quality of each worker. Although there are a handful of similarities between how the two professions operate, I think that it is unwise to make the factory worker connotation.

The entire idea of a factory worker is that they can be swapped in place by another and the output is maintained to a great extent. This just simply isn't the case in software or really any creative work. Even if we assume two workers have equal skill sets, something that is already dubious due to the importance of cross-domain knowledge in software, the personality one brings to a team will ultimately alter the entire team, sometimes good, sometimes not so. The social dynamic within groups is a critical element and something that cannot be commoditized away like other professions.

As to the point on commoditization within old tech, I can only answer with a "well duh, It's tech!". The goalposts are always moving within this profession. There used to be a whole heck of a lot of jobs in programming super low-level tasks, those are largely gone and have been replaced with new positions. Last year everyone worked on web apps, this year everyone was on mobile apps, next year it's anybody's guess.

airnomad2• 7 years ago

That's because our tools are not good enough so what we lack in tools we compensate by individual developer quality.

I spend a lot of time within WordPress ecosystem and I've seen people coming to me with 20K products shops they've built and maintain without a single line of code written.

I've seen companies operating online without having any developments either on contract or in house.

Because for certain simpler scenarios, there's UI based tools you can run your business on.

Sure they come to me because eventually they need something they can't do with tools they use but those are becoming more and more high level jobs.

Web development is pretty much figured out problem. You have legions of repleacable low value developers churning out pages and you have subset of highly paid specialists who can do more advanced things.

But those gazillions web pages are doing their job, they drive sales, improving information quality etc. so I could say digital workers are factory workers of our time.

On certain jobs line is blurry - designers can do basic WordPress but they also can set up MailChimp because machine needs to be humming.

tombert4• 7 years ago

About two years ago, I didn't get a promotion to "senior engineer" that I thought I was going to, and I had a huge temper-tantrum to my boss about it as a result (I'm still surprised to this day that I didn't quit on the spot, to be honest).

I was upset, because people that seemed to be contributing less and were less-qualified (at least from my admittedly-biased perspective at the time) were promoted to a higher level than me, and I got a fairly form-letter-esque answer of "we don't have the budget to promote you this time".

The next cycle, they corrected it, and I was officially a "senior engineer" on paper, and I realized how silly my hissy-fit had been. Sure, I guess having a bit more money was nice, but it's not like it radically changed the quality of my life, it's not like having a fancy title changed how people really saw me, and I didn't even bother updating the title on LinkedIn.

I don't think I was "wrong" in what I said. I do think that I deserved the promotion over someone else, but at the same time, I also tarnished a relationship with my boss and coworkers, and I let it get me far more depressed than it should have.

-------

I guess if any "junior" engineers are reading this, try and remember that a title is simply that: a title. They don't matter a lot, try to not get too upset over them, and obsessing over something so nominal is a great way to build up anxiety.

EDIT: Just a note, I absolutely think you should call out a company if you feel like you're being taken for granted. I'm not advocating complacency, just make sure that your hatred is directed to the right places and try to avoid getting too depressed.

irrational• 7 years ago

My title is senior application engineer. I don't think I've ever actually said that out loud. I just tell people I'm a developer. Titles are meaningless beyond letting HR know what salary band I should be in.

tombert4• 7 years ago

Yeah, same here. I was excited to get the promotion, but when people ask what I do for a living, I typically say "eccentric" for a more casual conversation, and "software engineer" for something more serious. I realize now that if you have to rely on titles for people to take you seriously, you probably aren't making great points.

linuxftw2• 7 years ago

Nah, f that mess. If you find yourself in a place that promotes the weak because it's a buddy system, it's not a place to work long-term. It means your boss is in 'don't rock the boat mode' and that's going to hold you back long term. Your boss should be fighting for promotions for their best workers and enabling growth in responsibility as well.

tombert4• 7 years ago

Oh, in fairness to my boss, he did make a strong effort in the next promotion cycle to get me promoted, which in fairness was only 6 months later.

The issue was the they had a limited budget for promotions, and basically limited it to one person per team. This, by itself wouldn't have bothered me too much, since the person who deserved it most on my team (someone with more experience than me, and was definitely under-leveled) did get promoted that cycle.

What upset me most was that a person on another team (with 1/3 of my experience, with no increased education, and on a team that accomplished nothing (not just my opinion, that team was disbanded a year later)) got promoted to a level higher than me. My direct boss didn't have any control on that team.

andreareina• 7 years ago

Senior is as senior does.

templ1232133• 7 years ago

Remember: once you retire, no one cares if you were a director. When you are 60, you are just old. The people that do care, you probably don't want to be friends with them.

ngngngng• 7 years ago

I'm currently wanting "senior" in my title because of a recurring issue with interviewing for new positions. I often get stuck at talking to HR because from my years of experience they assume I'm MUCH less expensive than I am. I could use the title so that I could stop running into this as much.

hiram1122• 7 years ago

I've always found the obsession with titles somewhat strange in our business. In my 7-8 jobs since college, I've never really had a 'formal' title. It just seems like all 'developers' are thrown into the same bin, and the better ones are team leads who don't have any actual authority to do anything (e.g. order a new laptop or approve of a hire).

After about 10 years, I just started calling myself a 'senior software engineer' on my resume and nobody has ever called me out on it.

Must be a Silicon Valley thing tied to salary. But in the areas I've worked, titles don't seem to exist for non-management.

tombert4• 7 years ago

I think it's the same compulsion that makes many (though not all) people who get a PhD feel like they have to mention that fact everywhere (e.g. Dr. John Doe, Ph.D.).

rsynnott• 7 years ago

I recently changed job, and went from being a "principal engineer" to being an "engineer" (in a company that doesn't do titles). There's more to life.

jmull• 7 years ago

Great post. Lot's of good stuff.

Just to comment on one part at random:

Code reviews would be more useful if review feedback was categorized:

1. is this a matter of personal style? 2. is this a judgement call? 3. is this something that is just wrong and has to be fixed? 4. is this in-scope or actually a separate issue?

(This is off the top of my head, so this is more of an example of the kind of categorization I'm talking about than a proposal.)

It's useful because it helps to set the direction and expectations on what to do about an item of feedback.

E.g. if you have a lot of 1. then the right "fix" might be to spin off a task to develop a common style-guide. (Or maybe fix an out-of-date a style guide, or to enforce an existing style-guide so that these issues don't dominate code reviews, etc.). For 4. the resolution would be to open a ticket (or whatever the process is so it gets proper consideration, prioritization, etc.)

Where I am currently we spend a lot of effort figuring out what to do about review feedback (and I think we too often make non-optimal decisions which sucks time as well).

DubiousPusher• 7 years ago

The last couple of teams I've been on have had the custom of prefixing any issue that is purely stylistic in nature with 'nit:'.

kannanvijayan• 7 years ago

I've been doing dev work for 20+ odd years now, and I suppose I can relate to many of these realizations. A young developer's framework is full of sharp polemics that soften over time as we scrape against them through experience. It's definitely something I look for in junior devs - a few strongly held opinions and a willingness to back them up by referring to some coherent "moral" framework - as long as this does not descend into technical dogma or dismissal of other perspectives.

If I were to step back and try to characterize the growth in my understanding of software development in a single general statement, putting aside all the hard-tack technical experience, it's this:

I am beginning to understand the subtle and complex delineation between _good_ and _useful_, and the role that execution plays in that - with all it's myriad parts: prioritization, management, technical risk mitigation and hypothesis validation, consensus building on technical direction, post-hoc validation, etc. etc.

And usefulness has a lot of facets in execution: not just technical but social. A good project and good idea might come to nothing if you are oblivious to obtaining some organizational mandate for it, and it gets sidelined due to shifts in priorities. If this happens, it means a misstep was made earlier: either the project should never have been started at all - due to awareness of upcoming priority changes, or you should have done the organizational consensus building to ensure that the work had the runway it needed to complete.

The same goes for technical consensus among implementors. Sometimes this can be avoided by giving clear mandates to trusted individual leads, but come complex projects really need the input of multiple senior members.

I'm starting to find lately that many of the contributions I'm most proud of are the ones where I come to firm conclusions on what work _not_ to do: concluding that certain tasks that were good but not useful enough, or determining ahead of time that certain planned implementation paths are actually not going to deliver what we might have expected them to, and thus we should scrap that idea. It has saved inordinate amounts of time that would _otherwise_ have been wasted.

The challenge for me has been reconciling this new understanding with my old methods for evaluating my own performance. I know these days, within reasonable bounds of arrogance, how to write decently complex software and understand it. As I move on to considering these higher level concerns, I find that I'm asking myself whether that opportunity cost is worth it: "I _could_ be spending time writing good code right now, instead of analysis and reports and meetings and planning. Is this new activity of mine _useful_?"

I'm still building my internal model for measuring my effectiveness in this new domain.. but it's clear that it's a profoundly impactful and worthwhile multi-factor optimization problem to tackle.

exabrial• 7 years ago

The #1 absolute truth I unlearned was: The solution to your problem is the tech stack or framework you're not using. Everyone in this industry seems to have tech wanderlust; using the latest and greatest and unproven is seen as sexy.

* "Oh we could do that, but we're on python 2.7"

* "Oh we could do that, but we're using Java"

* "Oh we could do that, but we're using a relational database"

rb8083• 7 years ago

One 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 everyone else's code. 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. I thought about this a lot and now I just go ahead and blaze a trail and other people can just figure out my style. Move fast and break things - or being reckless, its often hard to tell, but you wont be a 10x dev by trying to be nice and fit it.

chessturk3• 7 years ago

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.

ltc5505• 7 years ago

Interestingly, I'm at that unproductive phase right now. On one hand, I could fix this fast and ugly, but then my code is going to look no different then all the code I go home and complain about. On the other hand, I can try to make my code really nice and abstracted with well thought out design patterns like <golden-coworker>'s. So, on one hand I'm a hypocrite and on the other hand I'm slow and hardly productive because I am just learning design patterns and no matter how many times I refactor my code it never looks as good as <golden-coworkers>'s. How did you get out of this stage? Please help.

mceachen• 7 years ago

This is surely debatable, but the best code is readable by Engineers of Tomorrow with the least amount of effort.

Getting code reviews from other people that understand this, or pair programming with them, is the best way to practice empathy for those future code readers (which very well may be you).

Don't focus on commenting about how. They can read the code for that, and those comments almost always drift from truth. Instead, focus on writing code and comments that describe the why. Consider describing what other approaches you tried, why you didn't use them, and why you went with the current implementation.

This especially applies if your solution may not be the obvious first answer.

Try to help the Engineers of Tomorrow from repeating prior mistakes. Free them up to make new and grander mistakes, instead.

vortico3• 7 years ago

Perhaps the reason for "nobody writes tests" in the real-world isn't primarily because of time/cost, but because virtually no real potential bugs are testable. If you're writing a JPEG encoder or database model handler, yes, you can test that all day, but those things already exist and are well-tested for you. But if you're designing retail software or a web app, there are 2^10000 things that can go wrong, so most companies ignore automated unit testing in favor of human quality control.

wan23• 7 years ago

This is all wrong. When you have enough people working on a codebase such that not everyone knows everything about it, tests are a great way to document the behavior. They're much better than something like a wiki, in fact, because nobody actually keeps that kind of documentation up to date.

vortico3• 7 years ago

I'm not arguing that tests are useless. I'm arguing that tests are usually impossible. I invite you to suggest a test for https://github.com/VCVRack/Rack for example that could either 1) have prevented a bug, or 2) document the software's behavior.

nickda• 7 years ago

You only have 2^10000 if you have bad boundaries and overcoupling of your subsystems. Thus another benefit of unit testing is validating your architecture: bad architectures are inherently difficult to unit test.

vortico3• 7 years ago

bad boundaries and overcoupling of your subsystems

And that's the overwhelming majority of ways to make money with software. Think of every video game, desktop application, and mobile app that people purchase. What you call "bad boundary" isn't bad at all. The customers just expect the software to do 2^10000 combinations of possible things across N platforms on M hardware and integration with P external services. Imagine if you emailed a company's tech support saying that the CAD software you bought doesn't work with your Nvidia 1060, and they responded "sorry, that makes our sybsystems overcoupled".

docker_up5• 7 years ago

Overall 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" because a duplicate "probably wouldn't happen very often". Meanwhile, the consequences of a dupe would lead to a pretty bad customer experience.

I pushed back hard and forced the developer to rewrite his entire code. Would "good enough" be okay in this situation? My bar is much higher than this developer and I stand by my decision. We have the luxury of being tasked with solving customer problems and if we only strive for "good enough" every time instead of "the best I can do within the constraints I'm given", then in my opinion your career won't be very successful. We always have to make the best tradeoffs when it comes to time and expense, but the best developers are the ones that come up with the best solution and the best code that fits in a particular constraint.

mlent• 7 years ago

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 important not to confuse code quality with things that are more minor like idiosyncratic coding style.

Thanks for reading!

docker_up5• 7 years ago

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 comment on even the smallest bug I see, because that's what we're paid to do. So line by line "perfection" is what I believe we need to strive for in terms of code quality. Maybe not so much "perfection" but "best practices" might be a better way of stating it. We always need to strive for best practices so that our code is predictably easy to maintain, read, etc.

kemiller2002• 7 years ago

I understand what you are saying. I think what she's really referring to is: The perfect is the enemy of the good. You have to adhere to certain level of standards, but at some point you do have to admit there is a difference between, "this has problems", and "it's not how I would have done it, but it works and is more or less OK."

pdpi6• 7 years ago

You need to maintain a defined level of quality otherwise codebases go to shit very, very fast.

And it's that level that we call "good enough". Or, I would say, acceptably bad.

One of the most important lessons I've learnt over my career is that there is no such thing as "good" software. Everything could always suck less — anything that takes over 0.0 seconds is bad, more than 0kB of memory is bad, more than 0 lines of code is bad. However, your level of badness for each of these metrics might be something you're willing to live with.

It's like hygiene. What you call "nice and clean" for your toilet is not clean enough that you'd cook on it, and even your "immaculate" kitchen is unacceptable for, say, an OR. Hygiene is always "bad", you're just looking for a point where it's no longer unacceptably bad for your purpose.

brianmcc• 7 years ago

There's the "it'll do" mean of "good enough", which really isn't good enough. Then there's the "of sufficient quality" meaning, which is by definition good enough. The latter is the true minimum bar, IMO, and what I believe the author means?

mixmastamyk3• 7 years ago

Good enough is by definition, good enough.

It's up to the team and customers to decide on that however. Database integrity is particularly important, so with limited information, I'd say you made the right decision. Therefore the first draft of the code was not good enough.

So, we should all be in agreement now, right?

docker_up5• 7 years ago

Right, but who decides what "good enough" is? If I weren't code reviewing, then it would have passed as "good enough". And that's the point of why just saying good enough isn't good enough. There should be a threshold that no one fights over.

jiveturkey4• 7 years ago

You're getting some flack because "good enough" is too loaded and everyone reads it a little differently. No one seems to be reading your qualifier, "the consequences of a dupe would lead to a pretty bad customer experience."

Sometimes, good enough is good enough. If you were able to push back hard in this case, I take it you are senior to the other guy and your decision is/was justified by the product/feature requirements. IOW, in this case, good enough was in fact not good enough.

constraint

most important thing, right there.

chrshawkes3• 7 years ago

I don't think anybody would argue pushing bugs is good enough or qualifies as such under any circumstance. I think good enough means that no codebase is perfect and working with nitpicky perfect types is the absolute worst IMO. Not only that, I've seen those codebases too and they are often times just as convoluted and messy, although without trailing whitespace and no missing semicolons.

momokoko• 7 years ago

Codebases all go to shit pretty fast. That is really what you learn as a senior developer. The fully sustainable codebase is a myth. All codebases will inevitably get progressive more difficult to work on no matter what you or anyone else does.

All software eventually gets rewritten. Either in full or in parts. So "good enough" means "will this keep it going until this software, or piece of this software, is thrown away and replaced". Because that is typically much more economical than code review infighting causes 2-4 rewites of every feature until its perfect. Or spending 3 times more time on a feature to make it perfect. Or having to hire very expensive developers that are capable of writing to that high standard.

There are obvious exceptions in specific industries, but this holds true for 80%.

nurettin• 7 years ago

I have experienced great difficulties with literal spaghetti code written in delphi which one can only follow through debugging, but I have also seen large codebases written in kotlin and python where almost everything is in layers and it is obvious where to add a new feature and how to find one that doesn't work. And I was very afraid that the project would end up an entangled mess, but luckily, it had the right mixture of individual services (for scaling), monoliths and messaging mediums to not become a mess.

rafiki6• 7 years ago

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 guarantees ACID transactions in Casandra (that's a hard thing to do), and I'd really question the choice to use it to begin with.

Again without appropriate context, my bet here is that you guys are using Cassandra for other important features you won't get out of a typical RDBMS and as such you made a trade off to begin with and decided that Cassandra was "good enough".

Now the point I'm trying to illustrate (and I'm not just doing this to pick a fight, I promise), is that engineering is about trade offs and a big part of it is definitely related to likelihood of a problem occurring.

I think it also completely depends on the domain of the problem, the criticality of the process you're building and the outcome of a major failure of your assumptions.

So I'd just argue and say "good enough" is an entirely appropriate answer in many contexts and domains and it's important not to make a blanket assumption that it's wrong.

beat11• 7 years ago

That was my thought, too. If you need ACID transactions, use an ACID database. There are rather a lot of them. And then mirror the data out to Cassandra after the fact, if you need it there. Ironically, Cassandra may not be the source of truth!

Way back in the stone age, MySQL did not yet have ACID transactions. They got them about the same time they stopped bragging about how much faster they were than Oracle, but I digress. Anyway, I had to write a bunch of transactional code around it. Drove the dba and me nuts. We begged for Sybase (we both knew it well), but the startup CTO was an open source purist and hated his first contact with the Sybase sales machine.

Eventually they folded, and the point was moot.

docker_up5• 7 years ago

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.

gwbas1c• 7 years ago

Well, it's very clear that what the developer was trying to do was not "good enough."

rco8786• 7 years ago

I also think that a blatant disregard for correctness is not good enough. For me the good enough is more around style and architecture. If there’s an obvious bug, even if it only affects .1% of users it should be fixed. After all, if you have a million users your bug now affects 1,000 people.

Udik• 7 years ago

"good enough" because a duplicate "probably wouldn't happen very often". Meanwhile, the consequences of a dupe would lead to a pretty bad customer experience. [...] My bar is much higher than this developer...

I see a lot of posturing in this anecdote, what I think is missing are:

1 - an indication of how often would a customer experience the issue;

2 - how bad would his "bad experience" be;

Did you calculate the former and took in account the latter in forming your judgement?

Or, otherwise, was the "correct" solution simple and obvious enough that any non-junior developer would have picked that first without hesitation?

Too• 7 years ago

It's also a matter of dealing with the problem now while it's right in front of your eyes and you remember.

Generalizing here but assume 6 months later this rare duplicate happens for a very important customer so you can't just brush it off, you now really have to fix it. By then nobody remembers this code review so you don't even know if this duplicate is a one off rare event or if it is going to affect all customers. Fixing it in code review might have taken a few hours extra for one guy, now you sent the whole team scrambling weekend overtime just to find the issue and understand the implications.

jpfed• 7 years ago

But seriously, put in your damn semicolons.

typon2• 7 years ago

One thing I would say about the whole "good enough is good enough" mentality is that if everyone has that mentality in a company, your code quality will decline so far that it will be impossible to get anything done in the future. This has happened to my company because ten years ago people had this mentality and it did work for them, getting us a lot of market share and short term success due to high profit margin. However, today we are suffering immensely due to those decisions, losing customers and new hires because no one can get anything done except put out fires due to critical customer issues.

I think a healthy mix of idealists and realists is necessary.. With senior developers representing a good majority of the former.

templ1232133• 7 years ago

I think she covered that by mentioning that architecture is more important as a senior developer. My understanding as a senior developer by what she means is not to focus on optimizing the hell out of code. Too often, people would demand others use the most optimize piece of code, but if the code is only going to be called once or twice, you should focus your time on other things more important.

I think your company is suffering from bad architecture design more than anything else. It seems like everything is tightly coupled with little room for modifications. This probably means those senior developers weren't really senior to begin with. This tends to happen at startups where business is prioritized and people get hired with inflated titles. I have seen that happen in a lot of startups.

typon2• 7 years ago

What happened here was different. This is a top 25 Silicon Valley company, thousands of employees.. But with poor software habits. The people who designed the architecture were always under tight time constraints from upper management, so they always accepted the good enough approach.

But you are right! The company is suffering from horrible architecture.. And any attempts to change it are near impossible because of the sheer amount of code and processes that we have. It seems like a never ending battle

icsllaf• 7 years ago

I read “that orange website” all the damn time.

Is she talking about HN?

class_struggle• 7 years ago

Yes: https://twitter.com/monicalent/status/1137013118532558848

SamuelAdams2• 7 years ago

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.

cuddlecake2• 7 years ago

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 know, I'm just a junior developer.

SamuelAdams2• 7 years ago

Personally, I think the best thing is education. Now more than ever (in this agile / scrum world) devs are making small, quick changes to existing codebases. These small changes add up, and what was once a great, clean codebase is now riddled with hacks and mis-documented code.

I think educating the developer / team on the existing codebase first would be the right step. Spend a day just going through the code. Learn how it connects, learn the full scope of the project. After this, make your changes in a way that fit into the existing code.

I've had too many offshore developers re-imnplement existing functionality, like reading data from an excel spreadsheet, simply because they did not look through the code that was already there. It cost them 2 hours of work to add another library and implement it, when the code they already needed was a simple using statement away.

In theory, this is why good orgs have senior devs: they know the codebases already. Furthermore, they should be reviewing these changesets to call out devs who mis-document or scatter about the code. But senior devs are people too, and they miss things. Additionally, some codebases are enormously complex, and it's virtually impossible for a single dev to understand it completely.

oalessandr• 7 years ago

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.

randyrand• 7 years ago

Variable names can also go stale - you should consider replacing all the variable names with placeholders. /s

Deleting all the comments is too far in the extreme. How about just read them and realize they could be stale?

AdmiralAsshat• 7 years ago

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."

mevile• 7 years ago

Tests are a really important part of development. There's nothing wrong with suggesting tests. The wrong thing is to insist on it to the point it creates a conflict with you and your team. Either set an example and write tests and see if it creates value and your team is OK with it, make a convincing argument or if you think tests are needed very badly because everything is broken all the time and you can't convince anyone, get a new job. Sticking around and being bitter about it is the thing that's bad.

I usually ask upfront in an interview if the team writes tests and if they don't and I get the idea they don't want to I probably wouldn't work there.

himynameisdom2• 7 years ago

i think now more than ever, there needs to be a bridge mindset between technical and non-technical. i learned that very early on, and even spent some time in a customer-facing, non-technical role to hone my bridge mindset. the ability to have empathy for the end user, and everyone else upstream who will touch your logic, is paramount and takes care of a lot of issues.

it's up to us as technical professionals to care about both the "what" and the "how". the ability to pan in and out on a particular need was learned early on and i cannot be more thankful of that.

busterarm• 7 years ago

Some of us technical people like to be client-facing. The key is to make room for us to do that. Let us handle the client/user and then take meetings with us so we can filter what's appropriate to you.

The biggest problem with "technical people" is the desire to retreat to a pair of headphones and not communicate with anyone all day. Set aside some consistent portion of your day where that's the only time you'll take meetings and we'll work around your schedule.

himynameisdom2• 7 years ago

I agree. I enjoy speaking to prospects and clients, but I know not everyone feels the same way. I would say instead of letting technical people handle the client/user, it should be done in a collaborative way. Filtering shouldn't be necessary as that has the potential of keeping possible problems/solutions in the dark.

Technical and nontechnical people should collaborate face-to-face on a daily basis. That includes customer interactions.

kailuowang• 7 years ago

Epoché

asheikh• 7 years ago

My Absolute truth I unlearned as a Senior developer. your knowledge, hard work and quality of work is not important. The relationship that you have with your boss and your bank account is what you need to focus on.

colechristensen2• 7 years ago

You need to focus on all, not to switch between one and the other.

It doesn't matter if your work is amazing if nobody realizes it (unless you are fine being a starving artist, no judgement)

The corollary isn't that you should make everyone think your inadequate work is amazing. I don't think you personally are making that judgement but there are people who would.

hiram1122• 7 years ago

your knowledge, hard work and quality of work is not important.

Bingo. I used to be that guy who'd spend my weekends fixing the code that everyone else left messed up on Friday or at the bookstore reading up on the latest framework. And I thought that someday it would be recognized with promotions or more pay or even a pat on the back.

Nope.

The relationship that you have with your boss ...

I should have been the guy who was always socializing with management at the office and happy hours. I should have been pushing my way into positions that were closer to the money itself - like getting contracts, attending conferences with management, architecture etc.

This is becoming even more apparent as I hit middle age, and it's harder to justify my high salary when the majority of our code isn't really all that complicated.

and your bank account is what you need to focus on

But deep down I always knew this was true, so I lived frugally and saved most of my money. I honestly don't see a great future for guys like me who enjoy programming but are too introverted or just don't care to go into management positions. There is simply too many H1Bs, foreign competition, etc to justify high paid developers in most companies that aren't doing Google type development.

bradlys• 7 years ago

This is something I've noticed early on even as a junior engineer (maybe it's my general upbringing that highlighted this well known fact of life). It becomes obvious quite quickly how little your knowledge and work matters. You can be incredibly smart and come up with wonderful solutions but it won't mean a thing if your boss(es) doesn't like you.

For a profession that has frequently professed meritocracy - it is certainly not. It's unfortunate.

scriptkiddy• 7 years ago

I don't know if I can call myself a senior. (none of the companies I've worked for have used senior/junior in their job titles), but one of the most important pieces of information I've picked up is this:

The Simplest way is usually the right way.

What I mean is that fancy algorithms, sweeping design patterns, and "clever" pieces of code are generally not the best approach to 99% of coding specific problems.

Example: Nested for-loops. Generally a bad choice. When encountering a nested for-loop, one may be tempted to try and refactor it into some sort of recursive and highly-performant function with O(n) complexity, etc. You go through all that work and then realize that the most iterations that for loop will ever see is ~10. You just wasted a ton of time writing code that is more complex, harder to debug, and generally more opaque.

In my experience, I've seen this a lot in the context of premature optimization. I've also been the perpetrator many times as well.

Tactic• 7 years ago

Sidenote: I believe in general a Senior developer is 8-10 years with a general expectation that you will mentor junior developers.

YMMV depending upon region and company.

JustSomeNobody3• 7 years ago

Properly choosing an algorithm or data structure is first knowing the nature of your data.

jehna1• 7 years ago

Premature optimization comes in many forms, and at least these three cases are doing more harm than good:

1: "It's good practice"

For example: Wrapping every function implementation in a memoize function may seem like a good idea (= it prevents doing unnecessary work-heavy stuff), but it actually makes code both harder to read (more boilerplate to skip when reading) and most cases slower (= even when a function is executed only once, you're doing extra checks and function call).

2. "We're gonna need this soon"

For example: many times I've implemented an abstraction that makes sense for sharing code with a feature that I know we'll be implementing soon, only to find out priorities have changed and that other feature never gets implemented. What's left is an unnecessary abstraction that only makes the code harder to read and maintain.

3: Optimising for speed/lines of code

Unless you're building a game engine, it rarely makes bang for the buck to optimise for speed until you have identified an actual bottleneck in performance.

Same for one-liners. It may be cool that you know how to write 10-line function as one-liner nested ternary, but your "clever" code is probably less readable and harder to maintain.

templ1232133• 7 years ago

I agree. Title doesn't matter. There is so much title inflation in the industry today.

For me, becoming a senior developer has allowed me to see code more objectively than before. Instead of following convention to the T, I can now look at code and make my own judgement whether to follow the convention. It's great to have the sense of relieve.

alexhutcheson• 7 years ago

Multiple of these points could be grouped under the general belief that "Everything is equally important". The #1 change required for growing into a senior role is to form a habit of ruthless prioritization of how you spend your time (and your team's time, if applicable).

Often you end up in situations where all of the following are true:

1. Your teammate or colleague is designing or implementing something.

2. You have different ideas about how that thing should be done.

3. Your ideas would produce an objectively better system.

4. Even though (3) is true, the improvement to the system or design isn't worth the cost in your time, team velocity, team morale/development, etc.

In that case, the right move is not to intervene, and to let your teammate design/implement the system their way. This is hard to do, because most engineers are natural maximizers[1], but for most tasks you're much better off with a satisficing[2] approach. This isn't to say that you should never give feedback on designs or in code reviews - you absolutely should, but always remember that you have a limited budget for your own time and for team morale, and you should spend that budget on the feedback where it will make the biggest difference.

[1] https://en.wikipedia.org/wiki/Maximization_(psychology)

[2] https://en.wikipedia.org/wiki/Satisficing

bmon• 7 years ago

This really hits home to me. I worked on a project where I encountered an almost identical situation to the one you described. I stuck my foot down, and insisted we build the objectively better solution. We did, and only much later did I realise the damage I had done to my coworker's morale.

Looking back, I completely regret it. If I had my time again, I would stop after explaining the alternate solution. The time we would have had to spend fixing the problems with the original approach would have been worth it.

I've heard this repeated a lot, but I'm really only just starting to understand: Often the best leaders speak up less, rather than more.

edw519• 7 years ago

Excellent article! Thank you, Monica. You just put into words a whole bunch of stuff that I always "sensed" but never "said".

After spending 7 million years (it sure seems like it) cleaning up the most vile garbage code you could possibly imagine, I'd like to elaborate on this:

Architecture is more important than nitpicking. While a small line of code could be improved, the stuff that tends to cause bigger problems down the line are usually architectural. I should’ve focused more on the structure of the application than tiny bits of code early on.

Architecture = the sum of all those seemingly unimportant "tiny bits of code".

It seems like every time I have to refactor or (heaven forbid) rewrite, I have to start deep down in those tiny bits. I've worked places with all these "genius" architects, but when I dive deep down into the code, I find a sewer than couldn't possibly support software life as we know it, no matter how brilliantly it was conceived.

Fellow programmers, you probably know exactly what I'm talking about, all those cancerous tiny bits that kill even the strongest patients:

  - variables so horribly named that no one could ever interpret them
  - 800 line iterations surely destined to be broken by a maintenance programmer
  - conditionals so illogical that no one can tell if they ever worked
  - early exits to hell that can only be fixed by rewriting
  - double negative logic that could not never fail to break
  - 8 lines of code where 1 could do
  - <add your own>

Great architecture comes from both directions, "above" and "below". From my experience (unlearned as a junior developer :-) ), 90% of the problems have always seemed to come from below.

Get good at the trees and the forest will flourish.

chrshawkes3• 7 years ago

From my experience of working at Fortune 100's for over 10 years as a senior engineer, I would say I have seen what you described, but rarely if ever are they the architects fault. There are usually just a few of them and usually hundreds of developers constantly shoveling garbage into the codebase. They rely upon processes and such... but they all fall apart in practice.

I've come to the conclusion good is good enough and working is even better. Usually the business agrees.

reymus• 7 years ago

- early exits to hell that can only be fixed by rewriting What do you mean by that?

jiveturkey4• 7 years ago

  if (a) {
    do_something();
    return;
  } else if (b) {
    do_something();
    if (something_else() == -1) {
      return;
    }
  }
  
  do_other_things();
  
  maybe_exit_here();
  
  maybe_keep_going();

it has similarity to frequent `goto label` type of coding

mooreds• 7 years ago

"It's about the code." That is probably the biggest untruth I though when I was a new developer (I dislike the term "junior").

The truth: "It's not about the code, it's about the people."

macspoofing• 7 years ago

Good writup.

Imagine 50+ comments on your PR with all the semicolons you missed!

Depends. You should have a style guide and it should document what the expectation is. If it was decided that semicolons are mandatory, then code review should be failed. If they are optional than the code reviewer shouldn't flag it. The alternative is to use a linter/formatter and either auto-fail during a pull-request or have the tool fix it up.

cdevs• 7 years ago

I love the uncluttered ui for the site you work for https://sumup.com/ sticks the message to the potential customer instead of shoving lots of blog/jobs/other links all over the place as in the top menu.

jpswade• 7 years ago

I think much of this depends what you are employed to do.

Sometimes it's about making things less complex, which means good practices, code quality, clean code and testing means you can afford a bit more risk.

Equally, sometimes you employed to just get things done, make it work, even fake it till you make it, proof of concepts, minimum viable products, etc.

I've done both, I enjoy both, but they are two different modes of working.

Ultimately the answer is "it depends" and milage may vary.

Quality is a journey not a destination.

Yes, put delivering value above anything else, sometimes that value is quality.

jasonlhy• 7 years ago

1. Code and communication are the most important. If you are writing extremely bad code, you will be annoyed how much time you will need to go though to find the bug. The more you do, the more you will not like to touch the code even they are written by you. (I have seen someone with this experience) Understanding what your teammates are doing is also important in order to support each other and provide valued advices, in this case code is a communication medium.

2. To write good software, we cannot just be a coder, we need to understand the business and the project management

3. There are many seniors became senior because of their age not their ability. I am not talking about using a particular tech, I am talking about their mind. Many of them still think like junior even they are at a senior position, the way they are working didn’t scale at all.

4. Fundamentals is very important. https://hackernoon.com/the-doctor-and-the-scalpel-78656f508c...

iamleppert2• 7 years ago

"Good enough is good enough"

+1000 to this. Please don't be the guy that slows me down and prevents me from delivering features because you insist on everything being perfect. I can't tell you how many times and how much money people who are obsessed with code quality waste. They spend months polishing code only to get out a feature that no one uses and doesn't matter. But hey, the code is "perfect"!

illvm• 7 years ago

Who defines what "good enough" means? Is it basic functionality? What if that basic functionality contains security vulnerabilities? What if it is written in such a way that will cause potential, foreseeable problems down the road? What if it is written in such a way that it is only understandable to the author? What exactly is "good enough?"

iamleppert2• 7 years ago

I’ve found it’s far better to error on the side of speed and work pragmatically on features rather than trying to deliver perfection. That’s just me though. Nothing is going to be free of defect or perfectly secure.

ademup• 7 years ago

My junior thought: spending 3 days to optimize code to make the UI faster and use fewer resources will be appreciated by managers and users, so win-win.

My senior thought: spend 1 day to SOLVE the problem, and 5 minutes removing the code entirely.

seomis• 7 years ago

Over the course of my career, I've gone from deploying via scp, to svn-up/git-pull, to every variety of actual deployment pipeline imaginable with dedicated dev-ops teams. Now I'm the only engineer at a tiny 501(c)(3), git-pull straight from production again, and have never felt more free.

sytelus• 7 years ago

As you get older, the thing you unlearn is that there are no absolute truths.

jeremycw• 7 years ago

As a Junior: Creating the most abstract grand architecture to apply to every facet of my application will solve all my problems.

As a Senior: Replacing all this architecture astronaut indirection with simple linear concrete code will solve all my problems.

BentFranklin• 7 years ago

A paean to normalization of variance.

vowelless• 7 years ago

Great article. Related to the “code quality” point, what I have personally realized is that it’s easy to over complicate solutions. Often, a simple solution is better (especially when it is part of a larger, more complex system).

When I was younger, I liked clever solutions to show off my skills. Now I cringe at that. Other people have to read my code. And more importantly, “I” have to read my code tomorrow or next week. I’ve started to really prioritize simplicity. Which is ironically quite hard!

rq1• 7 years ago

What I learned as developper and Data Scientist is: either you know what you’re doing and can see the big picture, either you’re walking blindly to a “good enough” solution.

In the first case, I spend most of my time in architectural design and modelization. The implementation phase is rather quick, because everything is well defined and you can write a lot of tests upfront.

In the second case, you’ll discover the big picture by facing the problems while trying to find and implement a working solution.

While getting experienced means how fast can you figure out the big picture.

yters• 7 years ago

I disagree with the documentation one. I really think developers need to focus a whole lot more on documentation, possibly prioritizing it over code.

In fact, I think there should be something like a documentation driven development, where first devs change the description of what code should do, and then change or add the tests, and then finally write the code.

m0zg• 7 years ago

Interestingly, some of these absolute truths are absolutely true at larger (50+ devs, or so) companies because forward progress can't be made otherwise. System not documented? Might as well not exist at all. Code is not tested? Well, then nobody really knows if it works or not after even the most insignificant and peripheral changes. People don't treat code quality as a priority? Welcome to days/weeks/months of yak shaving to fix even the simplest issues. Good at communication but can't code worth a damn? Consider becoming a manager, not a "senior developer".

cm2187• 7 years ago

Absolute 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.

wltprgm4• 7 years ago

Most of the time legacy code and technical debt appearing on same project

craftoman• 7 years ago

How can you define seniors as pros? I know some senior devs that suck at programming, still coding in Perl using Notepad++ and their systems are full of bugs.

chasd00• 7 years ago

A good plan violently executed now is better than a perfect plan executed next week. - Patton

It's much better to get something, anything, on the screen and working than an elegant design constantly refined but never put to actual use.

parasubvert• 7 years ago

Not just "anything". Patton did say a "good" plan. A bad plan can tank you just as much as elegant design that isn't used.

perfunctory2• 7 years ago

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. Nada. Zip. Null. Undefined. NaN tests.

On my current project I have 100% test code coverage. Which I believe is quite unusual. But I am pretty sure that if I give a talk about how I did it, most people will be horrified.

kraftman• 7 years ago

Why would people be horrified?

perfunctory2• 7 years ago

Because it doesn't follow the best practices.

marktangotango• 7 years ago

I worked on a project that achieved 100% code coverage and still had loads of bugs. That’s precisely when I lost all faith in TDD.

james_s_tayler2• 7 years ago

"Not everyone will become senior during their career"

This. So much this. I didn't realise that until a little while ago but when I did it made me realise I need to understand actually what make someone a senior. It's not just an automatic progression.

saagarjha4• 7 years ago

I read “that orange website” all the damn time.

Yeah, don’t take the “orange website” too seriously.

draw_down• 7 years ago

Unless people are saying nice things to you on the orange website, then you definitely should listen!

saagarjha4• 7 years ago

I mean, it's often valuable to hear what people have to say about you, good or bad, but you also need to figure out when the feedback you're getting is not useful.

jonstewart• 7 years ago

The only thing to do when you implement a linter is fix the 800 errors it generates. It shouldn’t take long. That’s absolutely the right thing to do, and I’d happily back anyone on my team who does that.

harel2• 7 years ago

I've been programming professionally for well over 20 years (and many years prior as a hobby), and held "senior" to "C-level" positions. in my eyes I'm still a junior kid learning new stuff all the time. When I stop seeing myself as that, I'll switch vocation.

vonseel• 7 years ago

Early in your career, you can learn 10x more in a supportive team in 1 year, than coding on your own (or with minimal feedback) for 5 years.

Spot on!!!

xupybd• 7 years ago

No offence to other developers but this is the easiest read of any article I’ve ever read by a developer. I wish I could write like that. I also wish documentation was written by people with that talent.

saurabhnanda• 7 years ago

I must say this is a very well written blog post.

swaggyBoatswain• 7 years ago

I just started my first job as a junior-mid_level dev last week, my team is really awesome and I've been learning a lot. I'm the only junior dev on a team with 3 mid to senior devs, so there's lots to learn.

1: A great quote from one of the most senior developers I look up to town said this: a developer who's been developing for 1 year can have _far_ more experience than someone who's been doing it for 3 years. I find people who introduce themselves as "developer for 15 years" aren't those types, rather it's the ones that show innovation.

Another quote is this - to become a better developer, you need people at the same level as you, more experienced, and less experienced. So I've taken it upon myself to mentor junior developers in town. Other ways I've learned is by talking about technical challenges from multiple developers in multiple companies in my surrounding region, doing technical & lightning talks, and participating in hackathons.

2: I wasn't entirely surprised by how little testing there was even at companies that have been around for a 3+ years, I had learn that most companies in my area (even the ones that have great developers) - code test coverage was poor. There is an opportunity cost in testing something that might change later. As kent dodds put it, do some tests coverage on core features, but have integration tests

3: I think working with legacy codebases is a great way to learn. The codebase shows a story about how the scope of the project changed, how workarounds were made to meet client expectations in short turn around time, etc. These things you don't learn on your own. Being forced to break something down and build it into a better version is rewarding, so long as it's not everything you do.

4: My first code review was more informal, it was more pointing out everything I didn't consider when implementing a feature. E.g deleting old unused code, formatting things semantically and expressively, etc. Was still setting up my dev env so there were a few grammatical errors that didn't match eslint styleguides, but we had test runners for those.

5: Documentation to me has always been important, but forcing it upon others as a way to bookmark something I avoided. I think it's far better to just notate on a piece of paper your interpretation of how the code works, or write your own documents in Confluence/team-wikis so your senior dev can understand your interpretation of how things work. As the new dev on my team in a year, documentation was out of date and each dev only knew specific parts of the codebase, so I've been updating how everything works from a eagles-eye perspective. Those notes have a lot of value to the next dev that gets hired, because they come from a clean slate like yourself.

I also think, documentating your pseudo-code inside of tickets is important. I've learned the hard way from getting fired at a previous job many years back - you need to actively show your team what you do. Documentation is the lowest hanging fruit, you need to think about what you're going to say in your daily standup tomorrow, communication is essential

6: For me technical debt is really being able to identify where the debt lies. For instance, rails and laravel has well documented magic, but the path less traveled needs to be understood. My rule of thumb is if I'm going to write less-than-ideal code, it needs a comment block indicating why I did so. Don't push code you yourself don't want to read 6 months later

7: In regards to seniority, I think the best developers know they are junior in other areas and are multidisciplined in other fields besides programming. I've learned a lot of great wisdom from developers in my city's slack channel just by seeing conversations unfold. I know some first year developers whom I already consider senior, and some developers who've been doing this longer who I do not.

I think the most important thing I've learned in these 2 weeks in my first dev role, you can be a mediocre dev who just copypastes things and still be a great asset to any team. There's a lot of value in just documentation & communication alone

Other things I learned - you can bother your senior dev if they just sat-down or stoodup from their desk, or if their headphones are off. But experiment with communicating asynchronously in slack and synchronously in person and see what works and what doesn't - even if they sit right next to you.

At the crux of everything, it's important to have a certain growth mindset. I embrace a japanese methodology called LEAN. Other things - being okay with self-humilation is a great way to learn. Other things - force yourself to take breaks by only using small water bottles or none at all.

Also, make sure you say hello to everyone in the morning, my office is 20+ mechanical/electrical/civil engineers/designers, I make sure to say hi to them. I take the longer-route of walking through the frontdoor every morning, my boss makes fun of me for that. Give the gift of giving to others in the community, it reflects well on yourself, my team already had heard of me despite never meeting me b/c of how active I am in the local tech community. Rubber duckies are good inexpensive programmer gifts.

trpc• 7 years ago

That's the kind of talk I always hear from mediocre devs once they reach their first management job.

patsplat• 7 years ago

Learned as a junior: results matter Learned as a senior: stories matter

juanbyrge• 7 years ago

One thing I learned as a developer for 12+ years is that the title is meaningless and where I work, many of the highest impact developers would be considered 'junior' developers. I wonder why people have such an infatuation with the title 'junior' and 'senior'. Seems to be more prevalent in European countries.

Absolute truths I unlearned as junior developer

Related Stories