#beginners
19 posts

How to feel less overwhelmed as a developer

Identify the specific problem - be it too steep a learning curve, too much information incoming, too many responsibilities, peer pressure or your own expectations of yourself.
Read more

How to feel less overwhelmed as a developer

  • When you feel overwhelmed, either there is too much going on at once or you are overstimulated. Refocus and reprioritize.
  • Identify the specific problem - be it too steep a learning curve, too much information incoming, too many responsibilities, peer pressure or your own expectations of yourself.
  • Zero in on your key goals, set your boundaries, focus your ambitions, and recognize what’s not really relevant to you.
  • Find a process for self-education. Don’t try to memorize everything, learn where to find the right information. Make a list of what you don’t know, and add to it every time you come across a new idea or a skill you don’t have. Sift through the content and establish your key resources so you aren’t overwhelmed.
  • Beware of getting overwhelmed by other people. Make sure you have a balanced perspective on social pressure. Know that a lot of people write bad code, even great developers in great companies. People have different priorities and you don’t have to keep up with theirs. Remember that people will write about what is possible but you don’t need most of it on a day-to-day basis.
  • Work smarter by spending time on core skills like problem-solving, critical thinking and testing. Use proper project management tools to plan, manage tasks and track bugs. Take breaks for fresh air, exercise, and conversation so you don’t lose sight of the big picture. Ask your community for help with good resources, pointers or support with your workload.

Full post here, 9 mins read

Absolute truths I unlearned as a junior developer

Don’t be led by job titles alone. Value collaborative experience, being reviewed and having a mentor. Avoid an early position where you have to work alone.
Read more

Absolute truths I unlearned as a junior developer

  • The title of ‘senior developer’: Don’t be led by job titles alone. Value collaborative experience, being reviewed and having a mentor. Avoid an early position where you have to work alone.
  • Everyone writes tests: Loads of companies have little or no testing, because they have either never felt the pain of not having tests or felt the pain of having legacy tests.
  • We’re far behind everyone else: Beware of ‘tech FOMO’ as academic settings and conferences often cover proof of concepts rather than real-world scenarios. Dealing with legacy is normal.
  • Code quality matters most: Often, good enough code that works and is maintainable is good enough. Overarching architecture is more important than nitpicking.
  • Technical debt is bad: Disorganized or messy code is not the same as technical debt. Technical debt actually slows you down or causes errors or makes changes difficult. A certain amount of tech debt is healthy because it assures delivery.
  • Seniority means being the best programmer: Senior engineers need many skills, from communication and dependency management to estimation and project management. And the truth is that we all remain junior in some areas.

Full post here, 14 mins read

Hard truths for new software developers

You don’t need to reinvent the wheel to make a difference. In the early years of your career, aim to learn about others’ thought processes and why things are being done the way they are.
Read more

Hard truths for new software developers

  • Accept that you don’t know everything, that tech knowledge is competitive and that you have to keep working and learning to stay relevant throughout your career.
  • Acknowledge that social and soft skills matter as much as tech knowledge. You will need to hold mature human conversations that solve human problems to grow through your career.
  • You don’t need to reinvent the wheel to make a difference. In the early years of your career, aim to learn about others’ thought processes and why things are being done the way they are.
  • You will not always get the help you need, so seek out a mentor you can trust, who is also invested in your success and with a 5-10 years’ experience gap.
  • Your goal in the workforce is not just your success but that of the product. So assume that in interviews you are being evaluated not for accuracy but for brainstorming human factors that can affect the product’s success and learn to test for them.

Full post here, 9 mins read

Ways to stay motivated while learning to code

Aim for small incremental improvements. Look at the bigger picture of what you're enabling.
Read more

Ways to stay motivated while learning to code

  • You are going to spend a lot of time finding & fixing bugs. When you solve a problem completely, treat yourself.
  • Don’t learn to code - code to learn. Aim for small incremental improvements.
  • Amplify the positive, not negative. Don’t give in to the impostor syndrome. Learn to keep moving in spite of it.
  • Always look at the bigger picture of what you're enabling. Find and frame the reasons why you love your job.
  • Develop a hobby that gets your blood flowing, literally. Physical exercise helps a lot in staying motivated and focused!

Full post here, 14 mins read

These four ‘clean code’ tips will dramatically improve your engineering team’s productivity

‘If it isn’t tested, it’s broken’, so write lots of tests, especially unit tests. Code not covered by a test gets invisibly broken until customers spot the bug.
Read more

These four ‘clean code’ tips will dramatically improve your engineering team’s productivity

Top strategies based on Robert Martin’s Clean Code:

  • ‘If it isn’t tested, it’s broken’, so write lots of tests, especially unit tests. Code not covered by a test gets invisibly broken until customers spot the bug.
  • Choose meaningful, short, precise names for variables, classes and functions and make it easy to find files by name. In case of conflict, choose precision over brevity.
  • Keep classes and functions small - four lines per function and 100 lines per class at most - and make them obey the single responsibility principle. This will help with documenting code better as you will have lots of well-named sub-functions.
  • Ensure functions have no side effects (such as modifying an input argument), and specify this explicitly in the function contracts if possible (such as passing in native types or objects that have no setters).

Full post here, 7 mins read