Consensus Consensus
Consensus
Consensus Light Version Logo 3
  • Buyer Enablement
  • Platform
        • Interactive Video DemosEasily shareable and always available
        • Demolytics™Tantalizingly good stakeholder insights
        • Supporting ContentConveniently mapped content for each demo
        • OverviewIntelligent demo automation
        • IntegrationsCarefully curated integrations that work where you work
        • SolutionsPlatform tuning for teams across the funnel
        • SecurityGlobally reliable — way more fun than you think
        • ToursCreate on-demand product tours
        • Illustration of a calculator

          CALCULATE YOUR ROI
          WITH CONSENSUS.

          LET'S GO
  • Pricing
  • Resources
        • BlogThe #1 blog for Presales
        • Research & GuidesData and insights to help you scale
        • CustomersReal disruptors seeing real results
        • DEMOFESTThe best event for presales best practices
        • WebinarsThe how-to hub for scaling presales
        • Cost of Demo CalculatorDo you know the cost of your demos? Find out now
        • PodcastAnswers to burning Presales questions
        • Buyer Level AssessmentGauge buyer champion’s change project difficulty
        • Filter by Custom Post Type
          Posts
          Webinars
          Demofest Videos
          Podcasts
          Infographics
          Filter by content type
          Custom post types
        • Choose Your Own Demo feature image
          Choose Your Own Demo
  • Company
        • AboutOur WHY to everything we do
        • Press releasesSplash worthy buzz
        • CareersHigh-growth with high rewards
        • Consensus Partner NetworkJoin the network
        • SupportConstantly up-leveling customer users
  • Solutions
        • PresalesAutomate repetitive Presales functions and scale instantly
        • ChannelsOnboard and enable channel partners fast
        • SalesShorten sales cycles and improve close rates
  • Talk To Sales
  • Watch a Demo
  • Sign In
  • Watch a Demo
  • Sign In

6 Things Junior Developers Should Learn Right Away

  • Blog
  • Garin Hess
  • March 22, 2016
  • best practices, Tips
Consensus

Check out this great, in-depth guest post from the CONSENSUS™ development team. Authors include Fumiko Richards, Stephen Felt and Rosy Grimaud. 

Let’s face it, being a junior developer isn’t easy.

bigstock-young-developers-twitterYou love what you do and you want to succeed at your craft. You are eager to learn the secret practices whereby one developer can be 10x as productive as another (see Steve McConnell’s blog post). And, you frequently alternate between states of apprehension ranging from finding a bug you are not equipped to handle, to euphoria, at finally discovering the solution for the bug that does appear.

But most importantly, you want to create quality code that is clear so that you can be proud of it, and your successor does not curse you for it. Especially if that successor is you returning to add a feature next month.

There is just so much to learn and so little time. The lessons that really stay with you are the ones where you stumble over in the dark and fall sprawling. As you blindly feel around to find some ray of light to lead you back on your way, you wonder how you ever got anything done. You never again stumble in that same dark spot, knowing what you know now.

In this post, we will put up a few lights in dark areas to help you avoid stumbling and get back you back up if you have fallen.

1: You should not simply compare floating-point numbers

One of our projects involved comparing data that was stored as floating-point numbers.

Here is an example from my own experience:

    If(a > b)  {  do_something();}

We saw strange results. As we began to test, many values made it through just fine and the code seemed to be working great. But as we looked at cases when the values seemed to be exactly equal (0.227 and 0.227, for example), the do_something function was still getting triggered.

Here are some things to consider before we dive into the solution:

Integers, which we think of as whole numbers (e.g. -1, 0, 333, 42) can be compared because they are stored as exact values.

Floating-point numbers are numbers with decimal points. “Wait!” you say, “Isn’t 1.1 exactly equal to 1.1?” The short answer is no, they are not. And if you think about it, this makes sense.

Take the number 1/11. Try dividing for yourself. Your result? Well, if you are using a calculator, you might one of these results:

0.090909090909091

0.00909090909091

0.0909090909

And if you grabbed a pencil and paper, you probably stopped at some point, too. Because the result is never ending (as far as we know) and your paper is only so wide.

Computers can only devote so much space to storing these numbers, too, so they “give up” after they have used up all 32 or 64 bits they have allotted to handling each number (excellent and detailed explanation)

The upshot is that floating-point numbers cannot be compared the same way integers are. If you do compare them, then you have created an exceptionally pernicious bug because languages, by and large, are perfectly happy to compare floating-point numbers.

Here are few solutions to this issue:

  1. Decide how many significant digits you need to store, and store them as an integer with an implicit exponent. For example, if you are running a store, consider storing prices as cents (199) instead of dollars and cents (1.99). If you are tracking durations, consider storing milliseconds (1110) instead of seconds (1.110). You have to decide how many digits are significant to you.
  1. If you must work with floats, decide, once again, how specific you need to be. For example, if you are tracking the duration of a phone call, it doesn’t really make sense to say, “That call was 1/10,000 of a second longer than the previous call.” When is the exact end of a call anyway? When both parties have ceased speaking? When one party presses a button to terminate the call? At any rate, your precision does not likely need to be ten-thousandths of a second.

So, to compare the two values, subtract one from the other, then decide whether the difference is big enough to count.

a = 36.12 seconds

b = 36.12 seconds

if( absolute_value(a – b) > .0001 ) {

 // they’re different enough! Do something…

}

2. Rules are made to be broken

Ok, not really, but sometimes rules need to be broken. Because every rule has a reason, if your circumstances do not match the reason, then you might need to break your rule.

For example, consider ternary operators. While they are not evil in themselves, stuffing too much logic into them, or nesting them can lead to nearly illegible code. And so, to avoid anyone getting carried away, we made a rule as a team to not use ternary operators.

So the rule is, don’t use ternary operators. But the reason is because nesting them or trying to do too much in a ternary operator leads to difficult-to-follow code.

But, what if the opposite is true? Not using ternary operators can lead to code that is much longer and hard to follow. Consider this contrived example (and imagine needing to test and initialize dozens of variables):

if(a > 0)

{

 b = a;

}

else

{

 b = 0;

}

This can be expressed using a ternary operator like so:

b = (a > 0)? a : 0

So, when circumstances don’t match the reason you made the rule in the first place, and breaking that rule leads to better code or a better practice, then break it.

3. The hardest bug to track down is no bug

When a bug is reported, a programer might set about searching to find the malfunctioning part of an application. We may try to replicate it in a test environment, or start poring over error logs. After all, once you find an issue, it is often easy to fix.  Tracking down the bug is the most time consuming part, right?

But what if there is no bug? How long can you search for something that isn’t there? The answer is: forever.

Some bugs are actually just a misunderstanding. Perhaps the reporter’s expectations are contrary to the proper behavior of the application. Imagine for a moment a library. If a book is due Friday, but not returned until 7 in the morning on Monday, is it past due? At my library, thankfully, it is not. But if a new librarian from another library is accustomed to a different policy, he or she would consider this past due. And for the new librarian, as well as the reporter of a bug, not meeting those expectations can seem like a bug in the system.

Sometimes, however, we do have a real bug, but it is not in our system or code.

Recently, our office’s Internet connection stopped working. Going back to what had changed, we realized we had reconfigured the wireless router the night before. We pounced on it, and took several steps to restore it back to health (yes, we turned it off and back on, too). But, we still had no Internet access.

We started to walk up the chain until we were outside of our building. It turned out that our Internet provider had suffered a backhoe and fiber optics-related incident. We could have kept fiddling with our wireless router for days and it would have made no difference, the problem was outside of our sphere entirely.

4. The next-hardest bug to track down is 2 bugs

There was what seemed to be one bug on one environment that could not be replicated on any other environment. The cron function kept repeating itself and firing off so many processes.

Because it seemed to be happening on only one environment, we thought the cause must be an environmental issue. But our search turned out no good cause for this issue. Next we looked at the functions trying to find any places we may have been looping. Perhaps a flaw in the logic was causing an infinite loop. And, again we had no good lead to the issue.  

As we debugged further, we realized that this was in fact a product of 2 issues. The first issue was comparing floating-points. When we did not need to take any action, because the values were supposed to be the same, the computer thought that one was bigger than the other. The second issue was that the command cron was using (wget) was set to keep rerunning the function if it timed out. So comparing floating-points caused each function to run a lot longer, and then wget kept calling itself over and over, since the server got impatient and responded with timeout error.

Because of the combination of these issues, a simple code issue (Comparing floating-points) behaved like it was caused by environmental issue. It took us down the wrong path in our search for a possible solution.

5. Never assume

To quote Sir Arthur Conan Doyle:

“How often have I said to you that when you have eliminated the impossible, whatever remains,however improbable, must be the truth?”

While debugging, assuming certain parts are working fine just because it looks good, and it was working the other day, could cause you to miss the real cause of the issue. Likewise, assuming certain functions of a new feature should work in a certain way without confirmation from the product manager could result in redoing the entire project.

As mentioned previously, when we had assumed that the cause of an issue was an environmental setting, it costed us a few hours. And ever since, we make sure that we are checking every part of the function, from the beginning to the end, and step by step. This process has allowed us to identify issues a lot quicker.

Never assume. It only makes animals out of all of us.

6. Pair programing is great

In the beginning, programming alone is great. You gets tickets assigned, and you fix the issues or get to create the new features. You get to work at your own pace, and feel productive. Then, our CTO mentioned that he wanted us to pair program often with each other. This made some of us feel very uncomfortable. Some had never pair programmed before, and everyone else’s extensive experience was intimidating to the junior developers.

Just as people have different styles of talking or writing, they also have different coding styles. It can range from something very small like how to indent lines (tabs vs spaces), to something bigger like how to organize a function, file, or project. Even thought processes are unique to the developer.

At first, it was awkward to get used to the other styles. But, once we’d made it past the awkward stage, we realized how much we were learning by pair programming. People can solve issues in different ways, so, as junior developers, we were exposed to more possible solutions and ways to arrive at those solutions. Coding all on our own would never have provided us that exposure, and the knowledge of so many hotkeys would have been beyond us.

Also, because there is more than one person coding, we can come up with different scenarios that could introduce a bug, and solve for those scenarios thus making more stable code.You might think it would take longer to pair program than working alone, since your thought process also has to be accounted for. But if you think of the time spent on fixing every issue QA finds after working alone on an issue, pair programming shortens that time significantly. It produces cleaner code and front loads the time spent going back and forth with QA.

These are just a few of the little things that you will get to experience in your programming career. And, as you learn more and experience more, you will grow as a developer. Use these tips and learned lessons of a junior developer to help keep you out of the dark. Eventually, you’ll set up enough light posts and guides as you code, making you efficient and maybe even a true senior developer.

PrevApp of the Month: Consensus
How to Close a 70k Deal in 30 DaysNext
  • Tags: best practices, Tips
Consensus is Intelligent Demo Automation that scales your presales function.
Watch an Automated Demo

More Interesting Posts

How Buyers Think – Overcoming Emotional ROI
May 9, 2023
Burning Presales Hot Tips
Burning Presales: Hot Tips from the Podcast
April 27, 2023
The Micro Demo
Micro Demo: Giving Prospects a Small Taste of What’s Possible
April 20, 2023

Presales » 6 Things Junior Developers Should Learn Right Away

Platform
  • Buyer Enablement
  • Overview
    • Interactive Video Demos
    • Demolytics
    • Integrations
    • Solutions
  • ROI Calculator
RESOURCES
  • Customers
  • Blog
  • Dojo
  • Webinars
  • DEMOFEST 2022
  • DEMOFESTx
  • Podcast
  • Buyer Level Assessment
COMPANY
  • About
  • Support
  • Careers
CONTACT US

info@goconsensus.com

801.653.0028

Talk To Sales

LAUNCH DEMO

© 2023 Consensus Sales, Inc. All rights reserved.
  • Privacy Policy
  • Terms of Service
Key Activity Gap Analysis

The Definitive Guide to the 6 Demo Types

Download ebook

Research: 2022 SE Report

The Rise of Demo Automation Aargon Research

The Definitive Guide to the 6 Demo Types


Research: 7 Immutable Strategies for Scaling Presales


6 Demo Types Infographic


5 Burning Presales Problems Sales Leaders Observe

2021 Sales Engineering Compensation & Workload Report

Let us know where you want to see us next year!

Windows 95


Filter by Categories
Articles
Blog
Channel Development
Entrepreneurship
Event
Guides
Marketing
News
Awards
In the Press
Press Releases
Outreach
Press Releases
Sales
Business Development
Buyer Enablement
Presales
Filter by Customer stories Category
Customer Story
Featured
TP2
Filter by Tags
Artificial Intelligence
Automation
B2B Sales
best practices
buyer enablement
Company
Deep C
demo automation
Demo types
DEMOFEST
Demolytics
Demolytics best practices
Interactive videos
Marketing
Presales
product News
Research
Sales
scaling presales
test tag
Tips
Filter by Research Category
Appendix
Buyer enablement
Featured
Guide
Infographic
Research
Filter by Demofest Category
2020
2021
2022
2023
London
Silicon Slopes
Silicon Valley
Filter by Podcasts Category
Featured
Podcast
Filter by Webinars Category
Buyer
Presales
Webinar
Filter by Tags
*Best practices
*Buyer enablemen
*Buyer enablement
*Scaling presales
6 demo types
analytics
automation
b2b
b2b sales
best practices
Blog 2
business development
business strategy
buyer enablement
channel
company
customer insights
Customer Stories
data analysis
Deep C
demo
demo automation
Demo Types
demo video
DEMOFEST
demolytics
Demolytics Scaling Presales
demos
digital presales
digital transformation
disruption
dojo
EBook
faq
industry analysis
Infographics
innovation
interactive demos
Interactive videos
market trends
marketing
new demo player
outreach
podcast
presales
Presales Sales
presentation skills
Press
press release
product demo
product demonstrations
Product News
remote
Research
sale
sales
sales teams
scaling presales
Table of Contents
technology trends
Tips
virtual event
webinar
wfh