What are the unwritten rules of development?

What underlying rules govern our work?

Which are good and which need to be dropped?

Did you find this post useful? Show some love!

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

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.

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.

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.

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

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

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.

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

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

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

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.

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.

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

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

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

Doesn't count anymore. It's written!

Ben Halpern DEV.TO FOUNDER

Hey there, we see you aren't signed in. (Yes you, the reader. This is a fake comment.)

Please consider creating an account on dev.to. It literally takes a few seconds and we'd appreciate the support so much. ❤️

Plus, no fake comments when you're signed in. 🙃

After spending the first half of my career in technical support, I wholeheartedly endorse this rule.

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

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

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.

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!

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

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

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

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.

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

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

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

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.

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

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.

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:

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.

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.

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

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

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

Stop trying to be clever.

Clever solutions < simple (or elegant) solutions.

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

There is nothing so permanent as a temporary fix.

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

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

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

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

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.

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.

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.

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

Everyone's indentation is correct.

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.

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.

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.

The best code is a code what is not written.

So the ideal application is one that does not exist?

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.

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

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.

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

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.

Classic DEV Post from Apr 16

How to begin a project with just an idea

Hi, I have an idea of an application, I'm excited about it, I'm a junior, I'm g...

READ POST
Follow @mshwf to see more of their posts in your feed.
Ben Halpern
A Canadian living in New York, having a lot of fun cultivating this community! Creator and webmaster of dev.to.
Trending on dev.to
How do you keep track of what you're reading?
#discuss
Devs using font ligatures, what's the selling point?
#discuss
What's your worst estimate story?
#discuss #story #estimate #carreer
Linux distro you are using for development?
#discuss #development
Learning to think like a programmer.
#discuss
What is your longest server uptime?
#discuss #sysadmin #linux
Why do developers have the toughest interviews in the world?
#interview #developer #discuss