loading...
Cover image for 101 Tips For Being A Great Programmer (& Human)

101 Tips For Being A Great Programmer (& Human)

emmabostian profile image Emma Bostian ✨ ・13 min read

1. Get good at Googling

Being a programmer is all about learning how to search for the answers to your questions. By learning to Google things effectively, you'll save a lot of development time.

2. Under promise and over deliver

It's better to let your team know a task will take three weeks and deliver in two than the other way around. By under promising and over delivering, you'll build trust.

Designer

3. Be nice to your designers; they're your friends

Designers provide solutions to user pain points. Learn from them and work cohesively to build effective products.

4. Find a mentor

Find someone you can learn from and bounce ideas off of. Coding Coach is a great place to get started if you need a technical mentor!

5. Be a mentor

Be someone others can learn from and bounce ideas off of. We'd love to have you as a mentor over at Coding Coach

6. Write useful comments

Write comments which explain the "why" and not the "what".

7. Name variables and functions appropriately

Functions and variables should accurately denote their purpose, so myCoolFunction won't fly.

8. Take vacations

We all need time to de-compress. Take that trip you've been wanting. Your brain and your co-workers will thank you.

9. Delete unused code

No reason to accrue more technical debt.

10. Learn to read code

Reading code is an undervalued skill, but an invaluable one.

11. Establish a healthy work/life balance

You need time to de-compress after a long workday. Shut off work notifications, remove apps off your phone.

Meeting

12. Only schedule necessary meetings

Can it be solved in an email or a Slack message? If so, avoid a meeting. If not, be conscious of the duration. Aim for less.

13. Pair program

Pair programming allows you to play the role of both teacher and student.

14. Write great emails

Learn to capture your audience in your emails by being succinct yet clear. Nobody wants to read your four-page email Jerry.

15. Get involved in the community

Surrounding yourself with like-minded people will motivate you to push through the lows.

Tree

16. Clean up your branches

Clean up your version control branches like you'd clean your house before your in-laws came for a visit. If you don't need it, discard it; don't just throw it in the closet.

17. Don't gate keep

Be inclusive. Don't tell others they aren't good enough to be in the industry. Everyone has value.

18. Keep learning

You've chosen a profession that requires continuous learning. Learn to love it.

19. Don't give up

It won't always be easy. But we all started at the same place. You can do it.

20. Take tasks that scare you

If it doesn't scare you, it isn't going to help you grow.

21. Clarify requirements before starting

You should understand the acceptance criteria before delving into writing the code. It will save you time and pain later down the line.

React

22. Have a toolbox

Have a set of tools which you know inside-and-out. Know which tools serve which purpose and when a project can benefit from using one over another.

23. Learn to love constructive criticism

Ask trusted colleagues and friends for constructive criticism. It will help you grow as a programmer and as a human.

24. Be open-minded

Technology changes, and it changes quickly. Don't oppose new technology; learn it and then form an opinion.

25. Stay relevant

Stay up-to-date on the latest tech news by following publications, blogs, podcasts, and tech news.

26. Focus on problem solving

Strong problem solving skills can conquer any problem. Hone in on what it takes to solve a problem.

27. Stay humble

No matter what title you hold or what company you work form, stay humble.

Presentation

28. Learn to give a great presentation

Learn how to captivate your audience and give effective presentations.

29. Examine all solutions before jumping in

Don't jump straight into the first possible solution. Examine all paths before delving into the code.

30. Find your niche

There are many divisions within the tech industry. Find the area that interests you most and become an expert.

31. Develop good habits

Try to build consistent, and healthy, habits such as removing distractions, time-boxing tasks, being present in meetings, and starting with the most important task first. It might take some getting used to but it will be worth it in the long-run.

Debug

32. Learn to debug

Explore the browser debugger tools. Learn the ins-and-outs of debugging with your IDE. By learning the most effective methods for debugging a problem and tracing errors, you'll be able to solve even the most difficult bugs.

33. Exercise your current skills

Just because you currently know a skill doesn't mean you shouldn't exercise it. Skills fade with time unless consciously improved upon, and this industry evolves so rapidly it's important to keep practicing. Get out of the mindset that "I've always done it this way" and into the mindset of "Is there a better way to do this?"

Just because you've got a six pack now, doesn't mean you can eat a 🍩 a day and stay that way.

34. Understand the why

There will be times when you have to voice your opinion, so it's important to understand the why behind it. Why is solution A better than solution B? Provide a valid argument and your opinions will be much more sound.

Money

35. Know your worth

You are a commodity, and should be paid appropriately. Be aware of the industry averages in your geographic location. If you're making less money, it's time to have a chat with your manager. Go after what you deserve.

36. Don't be afraid to ask for help

If you're stuck on a problem and spending too much time searching for a solution, it's time to ask for help. We're all human. We all need help. There is no shame in reaching out to a colleague for support.

37. Learn to learn

People learn in different ways. Some learn best through video tutorials, others through reading a book. Figure out your learning style and practice it diligently.

38. Be kind

There will be times when you're asked to provide feedback on a colleague. Be kind. You can voice your opinions about Deborah's lack of initiative without ripping her to shreds.

39. Take breaks

It's nearly impossible to spend 8 consecutive hours coding. You'll burn out quickly and make a lot of mistakes. So set a timer to remind yourself to stop and take a break. Go for a walk. Get a coffee with a colleague. Stepping away from the screen will positively impact your productivity and the quality of your work.

40. Track your progress

Learning to code takes time and can be extremely disheartening when you don't see progress. So it's important to track your achievements and progress towards your goals. Keep a small list next to your computer and each time you achieve something, write it down, no matter how small. Atomic achievements compound to much larger rewards.

React

41. Don't rely on a framework or library

Learn the nuances of a language better than the ins-and-outs of a framework or library. You don't necessarily need to learn one before another, but understanding why a framework or library works the way it does will help you write cleaner and more performant code.

42. Learn to love code reviews

Having someone read and analyze your code can be terrifying, but can offer you invaluable feedback which will make you a better programmer. You should also work on your ability to conduct a good code review.

43. Learn about tangential spaces

Learn some basics about tangential spaces, such as design, marketing, frontend development or backend development. It will help you to become a more well-rounded programmer.

44. Don't choose the comfortable technology; choose the right one

Each project will have different needs, and as such we must choose the right tools for the job. Although it's comfortable to choose technologies you've worked with previously, if they don't suit the needs of the project, alternatives should be explored.

45. Take responsibility for your mistakes

All humans make mistakes and you will many many throughout your career. Thus it's important to own up and take responsibility when you've made a mistake. It will build trust with your team members and management.

46. Review your own code

Before opening a pull request, review your own code. If this were the work of a colleague, what comments would you make? It's important to first try to diagnose problems or mistakes before requesting a code review.

47. Learn from your failures

Failure is simply not achieving the expected outcome, and is not necessarily a bad thing. We all have many failures during the course of our careers. Learn from your downfalls. What can you do differently next time?

48. Recognize your weaknesses

Get to know yourself. What are your weaknesses? Maybe you always forget to update the tests before pushing. Or maybe you are really bad at replying to emails. Learn your weaknesses so you can actively work to address them.

49. Stay curious

This industry is ever-evolving, so curiosity will be important. If you don't understand something, be it a project requirement or a line of code, speak up. Nobody will criticize you for asking for clarification and you'll create better code as a result.

Book

50. Don't try to learn everything

There is an infinity pool of knowledge in the world and it is simply impossible to conquer it all. Pick several topics to master and leave the rest be. You can acquire working or tangential knowledge about other areas, but you cannot possibly master everything.

51. Kill your darlings

Just because you write some code doesn't mean you need t be emotionally attached to it. Nobody likes their work being thrown out, but code has a life cycle, so there's no need to be territorial about it.

52. Have your team's back

Good teams have each others' backs. This creates a safe space to try new things without fear of retribution.

53. Find inspiration in the community

Find a few people in the industry you admire. It will inspire you to keep working on your projects or try new things.

54. Value your work

Regardless of how much experience you have or what your job title is, your work has value. Give it the value it deserves.

Phone

55. Disable distractions

Turning off Slack notifications, text messages, emails, and social media will help you focus and maximize your workday.Jerry won't fall apart if it takes you 30 minutes to respond to his message.

56. Be supportive

Try and support your team members whether that's by attending an important presentation or helping them if they get stuck.

57. Give credit where credit is due

If someone does great work, tell them. Positive re-enforcement is a great way to build trust with your team members and help their careers. They'll be more likely to help you along as well.

58. Test your code

Tests are important. Unit tests, regression tests, integration tests, end-to-end tests. Test your code and your product will be much more stable.

59. Plan out your approach

When you receive a new feature request or get a new bug ticket, first plan your attack. What do you need to solve this problem or develop this feature? Taking even just a few minutes to plan your attack can save you hours of frustration.

60. Learn to pseudocode

Pseudocoding is a great skill to have because it allows you to think through complex problems without wasting time writing lines of code. Write an approach down on paper, run through different test cases and see where the pitfalls are.

Win

61. Keep track of your achievements

If you win an award at work, write it down. If you develop a crucial feature, write it down. You'll create a backlog of things which can aid with a promotion or boost your morale on a tough day.

62. Learn programming foundations

Learn some basic sorting and searching algorithms and data structures. These are language-agnostic and can help you solve problems across languages.

63. Choose technology for longevity & maintainability

Although it's fun to test out the newest technologies, pick those which will be easy to maintain within an enterprise application. Your team will thank you for years to come.

64. Learn design patterns

Design patterns are useful tools for architecting code. You may not need them for every project, but having a basic understanding of them will help scaffold out larger applications.

65. Reduce ambiguity

Instead of writing convoluted code which shows off your snazzy programming skills, aim for readability and simplicity. This will make it easier for your team members to contribute.

Debt

66. Pay off technical debt

Technical debt can have massive performance implications, so if you're able to refactor, you should.

67. Ship often

Instead of shipping a massive upgrade once every month, ship more frequently with smaller changelogs. You're less likely to introduce bugs and breaking changes.

68. Commit early and often

Committing early and committing often is the best way to ensure that your work remains clean and also reduces the stress of accidentally reverting important changes.

69. Learn when to ask for help

Not only should you not be afraid to ask for help, but you should learn when to ask for help. You should always try to solve a problem before asking for help, and keep track of the things you try. But when you've been stumped by a simple problem for over an hour, the cost outweighs the benefit, and you should reach out to a colleague.

70. Ask effective questions

When asking a question, try to be as specific as possible.

71. Get feedback on unfinished work

Your work doesn't need to be finished for you to get feedback. If you're uncertain of the direction, ask a trusted colleague to review the validity of your solution.

Read

72. Read documentation

Documentation is the purest source of truth about a technology, so learning to read it can quickly help you to become an expert.

73. Try all the things

Nothing is stopping you from trying a solution to a problem. What do you have to lose?

74. Speak up in meetings

Your ideas and opinions are valuable so participating in meetings will help you develop a rapport with your team as well as management.

75. Collaborate cross-team

If you get an opportunity to with with another team in your company, go for it.

76. Have passion projects

When you work 40 hours a week, it's important to take time for passion projects. They help you reinvigorate your love of programming and try new technologies you might not have access to at work.

77. Define your career goals

It's important to have an idea of your ideal trajectory for your career. If you don't, you're trying to shoot an arrow without having a target.

Talk

78. Get involved in the conversation

Comment on blogs, participate in Twitter threads. Engage with the community. You'll learn a lot more from being an active bystander than a wallflower.

79. Prioritize tasks

Learning to prioritize your tasks will help you enhance your productivity. Keep an active to-do list of immediate daily tasks as well as longer-term tasks and order them by most important.

80. Don't overlook the details

Details can make a big difference in a project.

81. Trust your teammates

Your teammates were hired for their skills. Use them and trust them to get the job done.

82. Learn to delegate

If you're in a leadership position, learn how to delegate effectively. It will save you time and frustration. You cannot do it all.

83. Don't compare yourself to others

The only thing you should compare yourself to is who you were yesterday.

84. Surround yourself with allies

Learning to program will be a long, and not always easy, journey. Surround yourself with the people who build you up and encourage you to keep going.

Build

85. Don't start for scale

Starting for scale is a surefire way to become overwhelmed. Build with scalability in mind, but don't start scaling until you need it. This way you don't overwhelm your team with unnecessary bloat, but you maintain the ability to grow.

86. Weigh performance implications

If you want to use a cool, new technology you should weigh the performance implications of doing so. Could you implement something similar without taking a performance hit? If so, you may want to re-think your approach.

87. Don't discriminate

Don't discriminate against new technologies or ideas. Be open-minded about the possibility of learning new skills. Also don't discriminate against people. We all deserve respect.

88. Apply for jobs you aren't qualified for

You will never meet every requirement for a job. So take a chance and apply! What do you have to lose?

89. Modularize your code

You could write all of your code in one long file, but this isn't maintainable. By modularizing, we ensure that our code is easily digestible and testable.

90. Don't JUST copy and paste

If you're going to copy and paste a solution from Stack Overflow, you should understand exactly what it does. Be intentional about the code you choose to introduce.

Coding

91. Create an inspiring environment/setup

You'll be much more motivated to work if you enjoy your workspace and technical setup. Make it you.

92. Remember where you came from

We all started from the same place. As your skills and your job titles evolve, don't forget where you came from.

93. Try to remain optimistic

If something goes wrong, try and be optimistic. Tomorrow is a new day. Optimism will help your team dynamic and your mental health.

94. Continually re-assess your workflow

Just because something works now doesn't mean it always will. Re-evaluate your workflow and make adjustments where necessary.

95. Learn how to work from home

If you have the ability to work from home, learn to do so effectively. Find a separate office space, devoid of distractions. Boneskull wrote a great article on working from home you should check out.

Accessibility

96. Code for accessibility

Accessibility isn't an afterthought, and it doesn't have to be difficult. Everyone should be able to use your products.

97. Honor your commitments

If you tell someone you'll deliver something by a certain date, honor that commitment. And if you can no longer make the deadline, speak up early.

98. Be proactive

If you have some extra bandwidth, find a task to help your team! They'll be thankful you were proactive.

99. Build an amazing portfolio

A great portfolio sets you apart from the crowd. Use this as a chance to show off your programming and design skills!

100. Remember why you love programming

You got into this profession because it sparked an interest. If you're getting frustrated and resentful, take a break. Give yourself space to reignite your passion for programming.

101 Share your knowledge

If you learn something cool, share it! Present at a local meetup or conference. Teach your coworker or mentee during lunch. Sharing your knowledge reinforces your knowledge while spreading the wealth.


Finished

And that's it! I hope you enjoyed my tips for being a great programmer (and human)!

Posted on by:

emmabostian profile

Emma Bostian ✨

@emmabostian

Software Engineer, bibliophile, & cat mom

Discussion

markdown guide
 

Love the whole list...
Bunch of valuable points ❤️

I would add this one:

102 Do Physical Exercises

Preferably everyday (or at least 3 days a week).

Our jobs require sitting most of the times... And, in years this will have severe effects on the body.

I'm sure everyone loves a specific sport that he would love doing on a frequent basis.

 

100 push-up, 100 sit-ups, and 10km Run twice a week will make you one-punch-man :-)

 
 

Loool!!! All the S-heroes don't believe it and want me do?!

 

I agree on this list, and Yours 102 (could be in the 2nd in the list already)
I'd add:

103 Sleep enough!

 

Very true,
Your readiness depends on how well you recover (Mentally/Physically) during sleep. Surprisingly many factors have to be in order:

  • Enough hours, deep and rem stages
  • Get your pulse down early (during the deep sleep stage)
  • Get your Harth Rate Variation up (recovers your brain) etc,

I've been improving it by knowing what effects on those and using Oura to track it (Anyone knows about that nordic high-tech startup? ouraring.com/ )

For me and most of us those are just simple things:

  • Go early to bed, and always around the same time
  • Enough sleep in hours
  • No screentime (definitely no emails/work) before going to bed (Stress is lowering my HRV ;/ )
  • No sports (heavy) before at least 3 hours before going to bed.

My last night stats (just a few of them):
Oura screenshot

 

+99!
Sleep is the key to almost every problem in life. I prioritize it over literally everything.

Natural methods are best (easy on the melatonin) and I personally enjoy the US military method of sleeping I found here

 

HELL YEAH!

I'm astonished at the amount of programmers who sleep at 5 AM then wake up like 9 AM... yes, this could work, but it's NEVER sustainable in the long run.

 
 

One good way to get some of your exercise in is after each pomodoro, for your break, do 50 jumping jacks as fast as you can, and then sit right back done and start another pomo. I've started switching it up and doing 10 pushups as fast as I can instead, and eventually want to work in situps. The key for me is to not have a pomo going while deciding what my priority is, checking email, or getting ready to work on a specific thing. Then in order to get the maximum productivity out of myself I decide on a goal which is a piece of my current priority project, which will take between 3-5 pomos. Any less than that and I lose productivity, any more and it is not as fun because I get worn out and have to take a longer break in between. After I complete my goal, I take a real break where I do something that involves my other senses and relaxes my brain. For example I might take the dog out to go potty, or wash a few dishes, or brush my teeth, or get dressed for the day. If you work from home you can try out starting work in your pajamas and then start getting showered and dressed and stuff on your breaks.

 
 

Nah, I hate physical exercise and I don't have a sport I like, I hate them all equally and I get tired easily because I have asthma.

 

Surfing? Horseback riding? Rollerblading?

What about martial arts? There's MMA, kickboxing/Muay Thai, Karate, Kung Fu/Wing Chun, or even knife and stick fighting in the Filipino Martial Arts!

Nah, I don't like them, I tried doing taekwondo when I was a kid but it was too boring and tiring.

Get a dog. I walk mine three times a day:
8am 45 minutes
3pm 20 minutes
8pm 10 minutes

Lost 5 pounds in 2 months!

I appreciate the advice but I don't think I'm responsible enough to take care of a dog, besides, I don't need to lose weight since I'm still not overweight xD.

 

I see... did you try tennis table? or yoga?

What kind of sports you find thrilling deep inside your heart?

None, the only things I like are Gaming, Playing guitar, watching anime, driving and frontend&backend development.

Are you sure you hate exercising? Often when somebody says they hate something they have bad memories, most likely due to poorly behaving people around. Are you letting these experiences control the rest of your life and keep you hating exercising, all the while the lack of moving adds far more issues on top of the asthma?

You can keep your current opinion, but over time your body would be like a code base that remains unmaintained with no refactoring at all, only adding up spaghetti solutions on top of another when you're trying to fix issues without admitting there is a core issue that needs a rewrite.

Nah, I hate it, I have asthma so I get tired quickly when doing any sort of physical exercise. And I'm a really picky eater(hate fruits and vegetables because of their smell, colour and texture) so it's really hard for me to be healthy(although I'm since my head doctor told me I was healthy).

I'm also really lazy so I usually refuse to do things that would take away some of my free time.

If I work 6-8 hours as a web developer I don't want to expend one or two hours running or doing exercise.

All I want to do on my free time is playing games, guitars and watching anime, since I work to be able to buy games, guitars, amplifiers and play anime.

Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

I don't care about those things. At all. You're a mediocre programmer and stay that way. That's what you say.

You can't call someone else a mediocre programmer because of something non-related to programming.

Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

I'm not calling it. That's what you're making yourself appear. You repeat your mantra of being lazy, uninterested in improving, and only being interested in very limited things. What else could I think of you as a programmer, too? Lazy, uninterested, unwilling of change or improvement, always keeping the same straight face "this is me" and not considering anything else.

In the end it is you who make yourself what you are. You gave me all the reasons to think of you as a mediocre programmer.

I gave you no reason since I didn't tell you which technologies I work with when I'm programming. What's wrong with being uninterested in improving things that don't affect the way I program?

There are many things in web-dev related programming I want to learn, and many things I want to avoid, most programmers are the same, they are interested towards a specific area and that doesn't makes them "MeDiOcRe PrOgRaMmErS" like you said.

Can I suggest something that might help your ashtma? I used to have ashtma up until I was 15 y/o. I understand how difficult it is.

After my last ashtma episode at age 15, I continue to suffer of terrible allergies up until a year ago. I would sneeze every morning as if I had a cold. Doctors had said that I was going to have this type of allergy until I die. I believed this bec. I, like most people, believe our doctors. One day I said to myself I would try to find a cure for this horrible 'morning allergy' as they called it.

I tried eliminating certain foods and writing down what I eliminated. The next day I would try something different. Finally after about 2 years of testing I realized that I was allergic to night shade vegetables. I have to mention that I also eliminated bread, cereals, pasta etc.

I don't have allergies anymore!!! I don't sneeze every morning. I feel fantastic! I also don't feel short of breath as I did once in a while before. I share this bec. it might help u. Ashtma is no fun.
What do I eat? I eat a mostly carnivore diet, 1 or 2 raw carrots(necessary to stay regular), cheese( I love cheese). I give myself a treat 2 or 3 pieces of chocolate about 60gr per day. I have personally discovered that vegetables might not be all good for all humans. Certainly tomatoes, zuccini, pickles are not my friends. If you want, give it a try you might find that u no longer have ashtma.

Even though I have asthma, I don't get asthma attacks since I was a kid, so I'm ok, except that I always get tired after running 50~ meters xD. The thing is that I can't eliminate food from my diet since I don't know how to cook and I'm not the one who cooks at home.

 
 

This should definitively be on the list! Along with the sleep part. Mind and body health is really important is you want to be good at anything.

 

include 103
learn how to post questions on stackoverflow otherwise credits/reputation will go in --
Jumping is the best exercise

 

I saw the title and thought "Huh, 101? I wonder how many of these tips are actually good?"

ALL OF THEM, apparently! Great post. This is now at the top of my list of articles to give to new programmers.

 
 
 

Awesome tips! Thanks for sharing, Emma! 😍

My personal favorites:

"39. Take breaks"

So much this. 🙌 It can be difficult to stop working when you just love what you're doing. But more often than not, breaks make you even more productive in the long run. Consistency is key, and you won't be able to keep up an unhealthy habit/routine.

"83. Don't compare yourself to others"

With today's connected society through social media, it's hard to not compare your own accomplishments with others'. But the only way to succeed yourself is to do the actual work—there are no shortcuts.

And remember that we all have something unique to give. Embrace that, don't wish you were in someone else's shoes!

"96. Code for accessibility"

No one should be left behind in this quickly emerging world ❤️

 

This is a fantastic list. Out of 101 you hit 99 percent bang on imho.

From my personal past experience and for my future career there are only 2 refinements I would make.

Under promise and overdeliver:
In specific working environments I would strive to "precisely promise, and precisely deliver".

In agile companies 'accurate' measures of the (ideal) effort something takes to do are valuable. If I say something will take longer than it will, this has knock on effects to other people relying on my estimation. Features are delayed needlessly, customers wait longer etc.

I'm all for few meetings but I think it's harder to generate accurate tasks/features/stories in these methods. Agile values face to face > remote asynchronous messages, and I've definitely seen the value in that.

Even so. 99.99... % agreement is miles more than I find in many other articles, so good work!

 

Even if not from the perspective of an agile company, or without the need for precise task managament, I'd be careful about over delivering as a constant commitment. I've been overdelivering for years (and not because of my choices, but because I overworked myself) and what has happened is that the "over" part has become the norm (back then), so any time I would state that something is out of reach, they'd point out I'd do my magic and take x days instead - and that's incredibly toxic for a very committed developer.

So my rule is that I will overdeliver if the "over" part is something that aligns with business requirements, is an easy win, or the effort/value is particularly good; and I have the actual energy to do that.

 

) Good work!

I guess you are one step near to write a book.

I know some books that did start with a list like this, laterl some items became paragraphs, sections and chapters.

Regarding:

  1. Take breaks

A good technique is to put a bottle of water in your desk and drink a lot.

Drinking water is very good for health and your bladder would remember the break.. Because you'll need to go to the bad.

 

Excellent list. Also, thank you for breaking it up occasionally with images; that's a thoughtful touch.

I am particularly fond of #83 (Don't Compare Yourself to Others), and wish I had learned that a decade or two earlier.

 

Holy content Batman! How long did this take to write? Was it a background thing over a couple weeks?

 

I wrote the tips over a few hours but it just took me a while to put it into a proper format :)

 
 

Shouldn't you mention @NinaLimpi at least once, considering almost all of these images are hers and have no attribution?

 
  1. I always mention UnDraw whenever anyone asks about the images.
  2. I promote her on Twitter all the time
  3. If you read the license, it says that no attribution is necessary.

I’m not sure if you meant to call me out rudely but it came off that way. I would never intentionally “not attribute” someone’s work to them. I have read the license.

 
  1. I have no way of knowing that
  2. I have no way of knowing that
  3. Obviously its hard for me to know about the license of an unattributed image. For the record I did look (briefly) before I posted my original comment and couldn’t find licensing info.

Not sure how what I said, came off as rude. I asked a direct question followed by an assertion of fact.

I appreciate your reply but I still stand by my original position, license or not. If it were one or two pictures, I would never have said anything. But this post is almost a portfolio for her. I’m sure if you asked her, she would come here and tell me she knows you and doesn’t care. But if it was my friend, their name would be somewhere in this post.

I hope you understand my position better.

Hey bud, you're wrong. Accept and get on.

What you think is right or wrong is not the case. The creator of the illustrations doens't want attribution. Read it here: undraw.co/license

"Oh BuT hOw CoUlD i KnOw?"

Exactly. If it were for you to know, the license were to be "give attribution".

Also, if you've really searched BRIEFLY for "undraw", Google gives you the option to go directly to the license page. Which ironically, is the number 1 rule of the article.

At no point have I been hostile or derogatory. Yet, you've felt the need to come in and essentially bully me because I have an opposing viewpoint to yours. In my comment, I clearly convey that I tried to search before saying anything.

Regardless of whether I'm wrong or right, this is not a mature response.

I think the challenge is that reading text on the Internet conveys no context whatsoever. I think a lot of people are rude in e-mail, but the truth is that they are trying to write short and to-the-point messages and not waste a ton of time on the e-mail itself when there are far more pressing matters to attend to.

Also, I personally find unsolicited advice-giving can be a minefield. It can make it seem like an attack on the author or come across as arrogant and it makes assumptions. Questions are my favorite way to open a dialog when I think something should be done in a different manner.

In this situation, you could have said something along the lines of "I have a very disciplined system for citing and crediting tools I use, and I noticed you didn't attribute X. Could you please tell me a little bit more about your citation process?" Then you can engage in a discussion that is hopefully productive, respectful and a benefit to all who read.

Seek to understand, rather than to be understood. Approach all topics with a beginner's mind. Be aware of the fact that you oftentimes do not know that you do not know something, if that makes sense.

When a conversation starts getting emotionally charged, take a step back. Go outside, I hear sunlight is really nice and I should be getting more of it :P Assumptions tend to lead to more assumptions which tends to lead to looking like an ass.

Lastly, consider appropriate venues. If you think someone is attributing wrong, a PM would probably be a much nicer way to get this across. No one likes public criticism. I know from the talks we've had together you're a good dude and you didn't mean ill-will, but it came across differently unfortunately. See if you can take something away from this experience!

I always appreciate your insight Scott, thanks for taking the time to evaluate the situation rationally.

I think the challenge is that reading text on the Internet conveys no context whatsoever. I think a lot of people are rude in e-mail, but the truth is that they are trying to write short and to-the-point messages and not waste a ton of time on the e-mail itself when there are far more pressing matters to attend to.

I agree. Although I still believe that there was nothing "rude" or "unrude" about what I said. It was definitely opinionated and direct, which is not something everyone appreciates.

Also, I personally find unsolicited advice-giving can be a minefield. It can make it seem like an attack on the author or come across as arrogant and it makes assumptions. Questions are my favorite way to open a dialog when I think something should be done in a different manner

To be fair, I did start with a question, so it's not just the form that matters. Again, agree with the overall sentiment. In fact, this observation is so great that I might write a blog post about it.

In this situation, you could have said something along the lines of "I have a very disciplined system for citing and crediting tools I use, and I noticed you didn't attribute X. Could you please tell me a little bit more about your citation process?" Then you can engage in a discussion that is hopefully productive, respectful and a benefit to all who read.

You're obviously right.

Seek to understand, rather than to be understood. Approach all topics with a beginner's mind. Be aware of the fact that you oftentimes do not know that you do not know something, if that makes sense.

I assume I know nothing, because no one does.

When a conversation starts getting emotionally charged, take a step back. Go outside, I hear sunlight is really nice and I should be getting more of it :P Assumptions tend to lead to more assumptions which tends to lead to looking like an ass.

I'm not emotional about this at all. I've played far too many hours of online games to get tilted by interactions on the internet (for better and worse).

Lastly, consider appropriate venues. If you think someone is attributing wrong, a PM would probably be a much nicer way to get this across. No one likes public criticism. I know from the talks we've had together you're a good dude and you didn't mean ill-will, but it came across differently unfortunately. See if you can take something away from this experience!

The first thing I tried was to direct message her. She has her DM's closed. That's a personal choice, but also voids that argument. It's not like I went to the Dev.to staff and complained or tweeted publicly about this issue. I went to the most direct place I could communicate with her and raised it.

Overall, I could have made the comment more digestible and friendly. Speaking of beginners mind, even if you evaluate the situation from the opposite view of mine

"Left a rude comment on the post about attribution"

I'm still only guilty of rudely commenting in the effort to defend someone else's work whom I don't really know. It's also a bit hard for me, because I received a similar comment just 1 week ago and handled it quite differently.

Overall, you gave me a lot to think about. Thanks for giving me an opportunity to improve!



No problem! Whenever I see the comments get a little uncomfortable, I try to step in because I'm one of our content moderators. My hope is that by reconstructing the events as a third party it can be turned into a learning experience for everyone who reads that far into the comments.

And at the end of the day, we're all adults and we should feel free to act like responsible adults. You're going to offend people for reasons beyond your understanding, there's always that person looking for any excuse to start a fight, and my generation is really guilty of "I believe in freedom of speech unless it goes against my beliefs."

Glad you got something constructive out of it!

 

I would add one more tip in your awesome tips :D

Shutdown all social links while programming (Facebook, Twitter, Insta etc)

They distract alot just about when you catch the point a message bumps up. :D

 

Awesome stuff :-D

I especially like "51. Kill your darlings". Too many developers have an unhealthy emotional attachment to their code, to the point where simple suggestions / questions are taken as attacks on the code. The code I wrote yesterday / last month / beginning of my career may be subject to improvement. Therefore I welcome discussions about my code and ways to improve. Sometimes I learn a new thing, and sometimes I teach a new thing with these sorts of discussions :-D

One important thing I also learned is to spot tunnel vision when it happens.

Whenever I'm trying to write some complicated clever code to solve a very specific problem, I take a step back and look at the big picture. Often times I'll see that what I was trying to do in one place was more efficiently done elsewhere, and my problem finds its resolution.

 

Thanks a lot for providing here tips for being a great programmer which are very beneficial for IT learners of Quality Dissertation where they are come to take coursework help UK with pass guarantee.

 

How do you write such no-nonsense, great posts? If I can replace all these 101 with one tip- I would say, just #CodeEveryDay and you will become the great programmer.

 

About 10% way down, I thought "I have to make a roadmap kanban board with this." Then It took a while to realize, this list is quite beefy for that.
Thank you for amazing advice. You have to write a book about it later.

 

Listen more than you talk
Learn by teaching
Don't be afraid to ask the dumb question
For every criticism, 10 compliments
Before you send that angry email/text, let it sit for 10 minutes
Revise, revise, revise

Great list Emma, I'm going to look at it regularly as a reminder

 

What a fantastic list of tangible and actionable items. This should be kept handy and Re-read often, especially when feeling uncertain or just blue. Thank you for putting such thought into this and for sharing.

 

Amazing tips, Emma!! 👏👏👏

I just wanted to expand on a couple of them:

  1. Keep learning

I think programmers should also develop the skill of self-learning.

New languages, new frameworks, and new techniques appear all the time (especially in some areas, such as front-end development). Being able to learn and discover things by yourself will give you a great advantage. Don't forget, however, Emma's tip #50 (Don't try to learn everything).

  1. Learn to love constructive criticism

Also, It's a good idea to learn how to give constructive criticism. A couple of years ago, I learned the "sandwich technique":

  • Start saying something positive about what you're evaluating
  • Continue with the things that should be improved. I know it sounds like a euphemism for "the things you did wrong", but it's actually important to frame it like this. After all, the aim of constructive criticism is to help the other person to improve.
  • Finish your evaluation with another positive aspect.
 

Wow, it was actually a hundred and one tips.

🤯👏🏽

 

Great article!

I'd like to add to #72:

Write documentation

Yes, it's a thing most developers neglect, but good documentation (be it API documentation, well documented code or prose about a project) helps yourself to grasp and reflect on what your code is all about; helps others understanding it; helps your three years older self understanding it when revisiting it. Also, learn how to write good, comprehensive, well structured and readable documentation.

 

Tip no. 46, Review your own code, is very important. It's easy to think all is well, since you wrote the code yourself, but it can be amazing what you discover about your own code when you review it yourself before submitting it for a code review. I created my own checklist to use when reviewing my own code and it was very helpful. The checklist includes things like, 1) Do the parameters of this method have appropriate guard clauses?, 2) Is this method too long?, 3) Are the names of my properties, methods, variables sufficiently clear?, etc.

 

Great article Emma, thanks for sharing this!

The most important one IMHO "The only thing you should compare yourself to is who you were yesterday"

And I would add, "Remember that this is about human beings working for and with human beings. No need to act like you´re not from this planet..."

 

Great list Emma. Thanks for sharing! :)

 
 

Great tips Emma.

I would add that:

When you finally solve a problem that you searched for online and couldn't find a solution, be kind to go back to that thread and provide the solution.

Doing so helps the next person that may find him/herself in the same position.

 

Emma! I loved your article,this have to be share with my coworkers ;)

 

Hi, Your article is very instructive,Could I translate it into Chinese?

 

That would be great, thanks! Just please link back to the original article!

 
 

No problem,I will do that and let you know then.

 

37. Learn to learn

People learn in different ways. Some learn best through video tutorials, others through reading a book. Figure out your learning style and practice it diligently.

And

50. Don't try to learn everything

There is an infinity pool of knowledge in the world and it is simply impossible to conquer it all. Pick several topics to master and leave the rest be. You can acquire working or tangential knowledge about other areas, but you cannot possibly master everything.

These go hand in hand. There's this dangerous myth about the "rockstar" developer, who knows everything off the top of their head. It's absolutely bunk. The folks that appear to be "rockstar" developers have simply learned how to learn. They know where to find a solution if they don't already know it!

If only I could go back in time and give my CS students this list!

 

I LOVE your article Emma! Very well done. The whole list is great.

Some thoughts I had while reading:

"...7. Name variables and functions appropriately..."
There are two real problems in computing:
Naming things
Cache invalidation
Off by one errors

"...17. Don't gate keep..."
IMO, programming has room for everyone. From toddler to retired.

"...51. Kill your darlings..."
I tell anyone I can '...when the code leaves your machine, it is not longer your code. Let it go."

"...64. Learn design patterns..."
Of everything I know today, I wish I knew this sooner.

 

This article is so good that I translated it in Korean and shared it. Related Links: medium.com/jaewoo/%ED%9B%8C%EB%A5%...

 

Really enjoyed the article. I read the whole thing which is to say it is well written and useful advice.

 

Nodding in approval to all of it, really impressive list. Thanks for compiling it! Appreciate the effort :)

 

Skills fade with time unless consciously improved upon, and this industry evolves so rapidly it's important to keep practicing.

Love this the most.