DEV Community

loading...

What are the unwritten rules of development?

Ben Halpern
A Canadian software developer who thinks he’s funny. He/Him.
・1 min read

What underlying rules govern our work?

Which are good and which need to be dropped?

Discussion (74)

Collapse
ignoreintuition profile image
Brian Greig

When you are looking over someone else’s code, before you criticize, recognize that they likely did what they did for a reason.

Collapse
bob_at_bh profile image
Bob Koon …amatata

100% this! When I do code reviews, I remember to always ask for clarification in a format like "what was the intent/your intention here?" instead of something like "why did you do it that way?"

As soon as one starts anything with "why", the receiver feels the need to be defensive. "Why" is an aggressive word and should be avoided.

Collapse
webreaper profile image
Mark Otway

Sorry, but "why" is not an aggressive word. Asking somebody why they did something is no more aggressive than asking what their intent was.

If "why" is coming across as aggressive in a code review, then it's because your overall code review experience is too adversarial, and needs to be reoriented to be more about achieving quality code, and less about blaming people for mistakes.

Collapse
supab3ans profile image
Shaprieh

I love this! In the words of Erykah Badu "I'm and artist and I'm sensitive about my..." Coding is definitely an extension of creativity. Sound advice to keep defensive feelings out of it.

Collapse
nektro profile image
Meghan (she/her) • Edited

You can't make a decision with information you don't have.

Collapse
rhymes profile image
rhymes

Great point! A corollary: don't judge the person by the quality of the code.

Collapse
raphael_jambalos profile image
Raphael Jambalos

That's true. People get better over time. And maybe the person who wrote that code is so much better now. I look down on the code I wrote 2 yrs ago, and that's just mark on the progress I made thus far.

Collapse
siwalikm profile image
Siwalik Mukherjee

Also an advise for code newbies, however stupid your code might look after reviews, never take review comments personally.

Your mentors have achieved a lot in their career and at some point, written crappy code too. So rather learn from their comments and be awesome. 🙌

Collapse
miku86 profile image
miku86 • Edited

I have an easy rule: Always start with a honest "Awesome, ...".
"Awesome, your code is very readable."
"Awesome, your layout is great."
"Awesome, your site looks great."
...

Collapse
nssimeonov profile image
Templar++

What if it's not?

Thread Thread
miku86 profile image
miku86

I think there's always one small thing.
"Awesome, you put some hard effort into it."

Thread Thread
nssimeonov profile image
Templar++

I appreciate your sarcasm :)

(in case it was not - read below)
I had two colleagues, who used to make me scream when seeing their code. First was so completely incompetent, that whatever he touched made significant regress, but he tried hard. Damn hard. He used to work for 10h/day and read tutorials for another few in his free time, but still 1 year and a half later he produced such unimaginable things, that I had to delete 80% of his code (and usually replace 10 lines with a single statement if at all).

The other one was competent, but sort of lazy and usually handed me code, where 60% of it was commented tests, some was incomplete and poorly tested. When asked to clean up his code he usually deleted the commented code... and a few lines of non-commented code inside them (yeah one can hardly spot them sometimes) and didn't even test before marking the task as complete.

Thread Thread
twigman08 profile image
Chad Smith

The first person is usually the type of person that I PERSONALLY will take time out of my day to sit next to and help out. Maybe code review the stuff together. I find that helps me fully get their thought process and I can explain my thought process more verbally and not just written. I personally have helped a few people that fit what you described (and I think more people who code review should do it).

The 2nd person should be brought up with to upper management in my mind. That's not fulfilling your job duties and his hurting the project and the company in the long run.

Collapse
thomasjunkos profile image
Thomas Junkツ

100% ACK. Additionally:

»the idea is not "why did you do this wrong" but "what made this seem like the right thing to do at the time to a reasonable and intelligent person in the situation?" -- Hard on systems. Soft on people.«

twitter.com/tottinge/status/105072...

Collapse
ben profile image
Ben Halpern Author

Damn that's a good rule.

Collapse
domitriusclark profile image
Domitrius • Edited

Learning how to ask the right questions (obviously) gets you the right answers BUT also helps you strengthen your understanding.

My mentor once told me 'A senior developer is just a developer that learned to ask the right questions by understanding the problem better'

Sticks with me everyday

Collapse
leahein profile image
Leah Einhorn • Edited

I love this! Do you have any suggestions on how to do that — how to ask the ‘right’ questions?

Collapse
domitriusclark profile image
Domitrius

I think the only answer to that is the cliche answer of time and building things. Once you build something unlike what you've built before, you'll find yourself tackling challenges that are new to you.

Your google-kwan-do will strengthen and you'll start to see others who have hit the same wall along with ways they accomplished it.

Collapse
selch profile image
selch

Don't release on Friday.

Collapse
dirtycode1337 profile image
Dirty-Co.de

That should be a point on every code-producing company's policy.

Collapse
moopet profile image
Ben Sinclair

There's only one, really, but I'm so bad at following it that I had to make it written

don't be a dick

Collapse
buinauskas profile image
Evaldas

Doesn't count anymore. It's written!

Collapse
spboyer profile image
Shayne Boyer

From a friend and mentor - "When you get to the top, send a ladder back down"

Collapse
guitarkat profile image
Kat

:) This makes me feel all the feels. I love it.

Collapse
jrohatiner profile image
Judith

Words to live by! Namaste!

Collapse
onejsninja profile image
Opesanya Adebayo

Sleep a little bit more. You'll squash your current bugs and have less of them to deal with in the next few days

Collapse
luqman10 profile image
Abdul Qadir Luqman

I can definitely relate with this one. Stepping away from your code (not necessarily sleeping), keeps you fresh and gives you a new angle of analyzing that stubborn bug.

Collapse
simonrice profile image
Simon Rice

I'd extend that to looking after yourself in general - getting enough to eat, drink, exercise and, as you rightly say, sleep! No code is worth losing your health & wellbeing over!

Collapse
rrampage profile image
Raunak Ramakrishnan

The fastest, safest and cleanest code is that which does not need to be written.

Collapse
jadjare profile image
jadjare

This is a rule I regularly promote.

Todo comments are not for bug fix reminders.
Todos are for acknowledging completed code could be done better but the current code meets requirements and is therefore shippable.

Collapse
elmuerte profile image
Michiel Hendriks

Yeah, we have // FIXME comments to remind us of bugs ;)

Collapse
rhymes profile image
rhymes • Edited

I am not saving lives.

Some developers write code with a lot of real life consequences, I'm not one of them. So I keep that in mind.

Collapse
edoxtator profile image
Doc

I had a boss who'd been in a Major in the Air Force, and had been wounded in combat. Whenever the debate over some technical point got very heated, he'd interject with, "Calm down. This isn't combat. Nobody is going to die if we pick the quick route over the safe route."

Collapse
rhymes profile image
rhymes

eheh great point :-)

Collapse
avjinder profile image
Avjinder • Edited

Exactly. I make mobile apps and crud apis and I still get so much anxiety over it. If I were writing code for airplanes, banks etc, I'd have anxiety 24/7. I'm still working on taking care of my anxiety but it's difficult.

Collapse
rhymes profile image
rhymes

take care of yourself Avjinder, that's the most important thing.

I don't have suggestions on how to combat anxiety but I remember this thread which talks about depression and anxiety. Maybe you can find some tips in there:

Thread Thread
avjinder profile image
Avjinder

Thank you for the link, it's really helpful. I am working on improving my mental health but the progress has been slow. I've chalked it up to this being my first professional job, and being handed a massive load of responsibility. I expect it to go away with time and experience, but only time will tell. One thing I've been recommended is to leave work at the workplace, and not bring it home with me. That has been helpful for me to a certain extent. Imposter syndrome is a bitch though, and cumbersome to get rid of.

Collapse
codingmindfully profile image
Daragh Byrne

You should read my article about programming and anxiety on DEV

Collapse
klabautercoder profile image
klabautercoder

Rule1: Write tests. Explain your processes in this tests.

Rule2: Write comments. Dont explain your code, explain why u wrote this code in this manner.

Rule3: Dont forget to do some research work before start coding. (Refresh your design pattern skills, architecture, dependencies around your projects, etc).

Collapse
romantolkachyov profile image
Roman Tolkachyov

The second assertion is controversial. The developer should not justify himself. He must share knowledge at first.

Collapse
cabe_bedlam profile image
Gregg Bond

There is nothing so permanent as a temporary fix.

More colloquially known here as "fix it in post".

Collapse
phlash909 profile image
Phil Ashby

I'm having fun trying to ensure that all features / fixes that we have going into service have a clear statement of what will enable them to be decommissioned, before they go live: giving the more malevolent of us a goal or two :)

Collapse
preciselyalyss profile image
Alyss 💜 • Edited

Stop trying to be clever.

Clever solutions < simple (or elegant) solutions.

I'd take a css solution over a javascript one any day.

Collapse
val_baca profile image
Valentin Baca

You've got that sign backward there :)

Collapse
preciselyalyss profile image
Alyss 💜

Thanks!

Collapse
carlymho profile image
Carly Ho 🌈

I think mine is actually that if there are rules, they should be written or codified somewhere! Strong communication and making no assumptions about what makes sense to other people I think is a must when working on a development team.

Collapse
phlash909 profile image
Phil Ashby

Corollary: a colleague will /always/ forget something important when communicating: most likely because it's the context of their issue and they are inside it. Be prepared to live in the dark for a while as you politely ask for explanations and they surface from their silo... sometimes resolving stuff in the process (hello Rubber Duck debugging!)

Collapse
carlymho profile image
Carly Ho 🌈

Oh, yeah, being prepared to ask questions and walk through stuff with people is like a real key underrated dev skill.

Collapse
jrohatiner profile image
Judith • Edited

Learn how to test
write good tests
test

Be creative. You're allowed to find answers from outside the box.
Stretch. Get up, move around. Learn how to walk away and come back later.
Read the code before you ask! Then ask, ask more, keep asking until you understand.
Learn how to ask good questions
Don't role your eyes
Offer to help when you are needed
Include everyone on the team in new initiatives

And most important of all

alt text

Collapse
thehanna profile image
Brian Hanna

Know your weaknesses, and don't be afraid to admit them.

I'm mainly a front end developer, and I have a lot of experience with server side tech (Apache, Tomcat, Node.js/Express/Koa/Sails/etc), as well as several flavors of Linux administration. I'm more than happy to do my best and answer any questions about those topics, as well as provide resources for learning more.

The minute you ask me a database question, I'm going to stop you, and tell you that I don't know enough to provide good or accurate information, and you're better off talking to a DBA. I can read SQL, I can write some (bad) SQL, I can use an ORM library to interact with a DB, and if it's Postgres, I can do enough on the command line to be dangerous. Outside of that, my knowledge of databases is very limited, and I make no attempt to hide this fact. I'm starting to learn more, but the fact of the matter is that for my day-to-day job, it's not needed

Collapse
ghost profile image
Ghost

Freelance Coder Rules To Live By...

  1. Nothing gets pushed to production after lunchtime Thursday....

  2. Do not schedule meetings on Fridays.

  3. Don't take calls from clients until after lunch Monday.

  4. Enjoy coding but remember, it's your profession, not your life.

Collapse
jakebman profile image
jakebman

Blame your code first.

Sure - it's possible that there's a bug in the library that 1,000 other people are using - but it's faaaar more likely that you're using it wrong, making an assumption you shouldn't, or even simply have a typo.

Bugs in other people's code do exist. But you're far more likely to see a bug in your own code that in someone else's. Blame your code first.

Collapse
clickclickonsal profile image
Sal Hernandez

That feature you build today maybe removed in the future. Once you realize this, it will allow you to iterate quicker. 😀

Collapse
jrohatiner profile image
Judith

So true!

Collapse
perigk profile image
Periklis Gkolias

A rule that shall be kept:

The continuous learning and sharing knowledge mentality. I believe the exponential'boom' of the last 10 years in our sector, is due to that, at one point of another.

For example, the ML popularity rise that happened, when Google chose to open source tensor flow

A rule that shall be abandoned:

Being labelled as anti social guys/girls. It is a bit unfair, but it is up to us to change it.

Collapse
jrohatiner profile image
Judith

great comment! Sometimes people seem anti social when they are nervous about making new friends. Reach out and make someone else feel welcome.

Collapse
mahlongumbs profile image
Mahlon Gumbs

For me, the only rule is

There are no rules; only guidelines that may become strict in certain situations.

I find that developers that say “never do xyz” tend to over complicate things when xyz becomes the best solution.

Collapse
threedeeprinter profile image
Dan Benge

Keep learning. Be aware of current trends. Learn new technologies, even if you're not using them professionally. No position is guaranteed to last forever and your knowledge can help you stumble onto better opportunities.

Collapse
schmidt profile image
Anders Schmidt Hansen

Already a lot of good ones. "When you point one finger, there are three fingers pointing back to you.", comes to mind. It's easy to blame others or kick downwards on colleagues who might not be as good as you think you are. If you do, you better be that much better yourself. Better yet, replace the blaming/high-horse-sitting altogether with humble understanding, teaching and helping people improve. 😊

Collapse
rachelsoderberg profile image
Rachel Soderberg

Push code relatively often, definitely at least before you go home for the day. This is the "you could get hit by a bus" rule.
If that's too dark... perhaps we could change it to the "you could get abducted by aliens" rule. Would hate for them to sweep you up after a long day of productive coding, only to leave your team with no way to access your latest changes!

Collapse
tonymet profile image
Tony Metzidis

Code with empathy. First for the customer, then for the team. Always think of the impact your work has on your teammates. If it's unstable, who are you keeping up at night to fix it? If it's unusable, no one will be there to pay your salary.

Collapse
andrewlucker profile image
Andrew Lucker

Everyone's indentation is correct.

Collapse
thomasthespacefox profile image
Thomas Leathers

Visuals<functionality.
Its much better to have an ugly UI, and a fully functional backend, than a backend that's in shambles and a UI that looking good is all it actually does.

Start where the project revolves
When you start with the center-most aspects of your project, it will usually wind up much more on-center oddly enough.

For example, with Desutezeoid, my point and click adventure game engine, i started with the core screen data format (XML) and some basic clickable text items that jump between screens, and worked from there. sure, it wasn't pretty at first, but now Desutezeoid has a solid plugin API, an animation system, inventory management, and a host of other features. and you know what? It even looks halfway decent.

Collapse
citizen428 profile image
Michael Kohl

I use the following system to triage work: I have a mental coordinate system, where the X axis goes from low impact to high impact and the Y axis goes from low complexity to high complexity. This gives us four quadrants:

  1. High complexity, high impact: this is generally why you're writing a piece of code in the first place, i.e. what makes your application worth writing. Deserving of the highest attention, comprehensive tests etc.
  2. Low complexity, hight impact: the low hanging fruit. Do as much of that as you can, whenever you can.
  3. Low complexity, low impact: You barely should find yourself doing work in this quadrant. It gives a false sense of productivity (due to the low complexity you can get a lot of stuff done), but doesn't really push the project forward.
  4. High complexity, low impact: I've you find yourself here, find something else to do.
Collapse
appius profile image
Vladyslav Ushakov

The best code is a code what is not written.

Collapse
itsmeseb profile image
Sebastian Kolind Sørensen

Write clean, simple and easy to read code, instead of fancy pancy :)

Collapse
javierg profile image
Javier Guerra

Developers are problem solvers. You should always question the need to solve it with software. Think how would you do it without a computer; maybe is a better solution.

Collapse
eaglerockdude profile image
ken mcfadden

don't bullshit.

Collapse
thomasjunkos profile image
Thomas Junkツ

Write code in such a style that you are able to understand the code even if you are suffering of partial amnesia. Leave waymarks in your code about your intention.

Collapse
jrohatiner profile image
Judith

Don't embed non-constructive comments, profanity or inside jokes

Collapse
dhandspikerwade profile image
Devin Handspiker-Wade

As a continuation, never use images in test that may offend a client. Even in local testing. Nobody as has ever been offended by a photo of a cute kitten.

A coworker had needed the show the client something on his laptop unexpectedly because the client environment was down for updates. Having Nick Cage gifs for every image didn't sit overly well with the client.

Collapse
revskill10 profile image
Truong Hoang Dung

Try and error is often how the AHA moments are made.