Daily posts from @fooyay about various topics including math, finance, coding, and progress on the app/website whencanyoudoit.com. Follow along on github or learn more about me.
Looking for Finance Fridays? I’ve moved my blog over to Medium. Tumblr’s technology was nice, especially the queueing, but I’m hoping to find a larger audience on Medium.
Know where you are going and what you are going to do.
Draw out a plan for you code before you start writing software for your next commit. This way, you’ll have a much stronger idea of what tests need to be written, what objects and methods will be involved, and what you need to integrate with.
Having a plan is called software architecture. Always know where you are going. Coding aimlessly and randomly will lead to trouble, rework, and delays.
It is good to enlist help in designing your plan. If you can easily explain your plan to another person, then you know it is a good plan. If they squint and furrow their brows and can’t follow your line of thought, then you need to improve or simplify your plan.
It is very easy to get caught up in a new fad. It may be a new framework, a new development pattern, a new tool, or whatever. A new version of Angular. The atom editor. The repository pattern. Machine learning. Internet of Things. There are countless examples.
Just remember, being popular in the press and on websites and blogs does not mean that the current hotness is the best tool for every job you have in front of you. Frequently, these are new things generating a lot of buzz, because they appeared to solve a specific problem in a cool new way, giving someone a huge advantage in a particular job.
Next thing you know, everyone wants to copy it. Uber for strawberry picking. Airbnb of skateboard rental. Snapchat for trainspotting. Blockchain for slurpees. And so on.
Soon people realize that just because it worked in one case doesn’t mean it will be the best tool for their job. Then the fad passes and people are on to the next new hotness.
The best tools prove themselves over time. So watch out when people dog pile onto the latest fad. It might not last.
For various reasons, some people feel afraid to speak plainly and tell the whole truth. They may sugar-coat details, they may leave off some details, or they might just refuse to comment at all. For people who are depending on the information you provide, how does this false version of information help anyone?
Never hide from bad news. Get out in front of it. If you did something wrong, admit it and own it. People will see that you are already correcting the mistake and have matters under control. But if you fail to be totally honest, people will still find out sooner or later. Then they’ll remember that not only did you do something wrong, you also tried to hide it, which just makes things worse.
Similarly, when someone is asking your opinion of something, they want an honest opinion. If they just wanted to you to echo their own thoughts, they would have asked one of their loyal friends instead. Clearly, by asking your opinion, they place value on your thoughts, on your perception of things. So in order to retain that value, you need to provide an honest assessment. If things are good, say they’re good, and explain why. If things are poor, likewise, say they’re poor, and explain what is wrong. Maybe you can give advice on how to improve things.
Honesty also applies to the visibility of information. Hiding information, keeping secrets, or neglecting to inform people are all different kinds of dishonesty. When you do this, you are presenting a misleading version of reality. People then use that incorrect version of the world to make other decisions, which can lead to a domino effect of a whole string of bad decisions.
Avoid secrets where possible. Most of the time, secrets are not necessary. Furthermore, the person who can share the most information, who can educate and inform others the most, tends to be recognized as having the most value because they a positive impact on the organization.
Honesty also builds trust, which doesn’t come easily at times.
A Variable’s Name Should Correlate to the Size of its Scope
The larger the scope, the harder it is to fully understand.
In a tight loop with a scope of one line, a variable’s name can be one letter. This is often an array index or some kind of counter.
As the scope gets larger, the variable name should become a word representing a business object.
When the scope of a variable exceed that of a single method, there definitely becomes a stronger chance of confusion, so the name may need to involve multiple words.
In all cases the variable’s name should be immediately obvious to the reader. And when they see a really long name, that should be a red flag to the reader that this variable may have an extended scope.
There’s not a lot to Kanban, which is one reason it is desirable.
Yes, you should be agile, and that means following the agile principles, and reading the agile manifesto. Past that you will find different agile methodologies, the most infamous one being Scrum. Kanban is much preferred, and a lot easier to implement. To do Kanban, there are three main things you need to do.
First, visualize your workflow. Make this visualization highly visible to everyone. Preferably, this Kanban board would be posted in plain view of the developers working the project. A Kanban board is very easy to create; you take a board and divide it into columns representing the different states of your workflow. Then as issues appear, they enter the first state by appearing as a sticky note on the left column. As work progresses through the other states, it moves across the board, through the different columns.
There are many web-based tools for doing an online Kanban board. In this age of remote work, an online board becomes more necessary.
The second step to good Kanban practice is to limit the amount of work in progress. This means to avoid multi-tasking. A developer should be working one story at a time. If a developer has ten stories open at once, and declares them all to be “in progress”, there will be very little progress. Often a “work in progress limit” is posted above a status column. Before additional post-its can be added to a column in excess of the posted limit, other post-its need to be removed from the column. Either they are promoted to the next step or pushed back to the backlog.
The third step for Kanban is measure and improve throughput. The two most common metrics are lead time (from appearing in the backlog to delivery) and cycle time (from work start to delivery). Lead time is more focused on how long a new idea will sit in the backlog on average, and when it gets too large, the team has too many projects pending. The larger it gets, the more likely there are stories in the backlog that will never, ever get completed.
Cycle time is more focused on the performance of the team doing work in progress. Obviously some stories are bigger than others, and thus cycle time represents an average. Generally, this system works best when most stories are roughly the same size. Try very hard to have extra-large stories, and break them up into smaller stories when you see them.
That’s it, that’s all there is to Kanban. If you can do the above three things, you can do Kanban.
Sometimes there are places where the build never completes successfully, yet people happily move along anyway. “Oh, that test always fails,” one might say. Well what good is a test whose failure is acceptable? Either fix the problem or remove the test. Clearly it doesn’t represent a real problem.
The build must stay green. When the red lights appear in the build, that needs to be a major call to action - something is wrong and must be fixed!
If having red lights in a build becomes acceptable, some really bad failures will eventually leak into production. Failures that should have been noticed and prevented.
This is hard when you are starting out, but if you keep contributing to your investment account, you’ll soon be able to have several positions. The main idea is that for each speculative trade, to limit your exposure to no more than 10% of your portfolio.
For example, if you’re going to invest in a new cryptocurrency, then the total exposure could be the entire position. It could go to zero. To limit your risk, the size of the position should be no greater than 10% of your total portfolio.
For safer bets, such as an S&P 500 mutual fund, your position can be larger, because it’s unlikely it will go to zero, so even if it is 40% of your portfolio, you limit the risk to 10% of the portfolio’s value pretty easily.
The other danger to look out for here is correlated investments. For example, if your portfolio contains nothing but tech stocks, and the tech industry takes a hit, then everything is going to down together. So while risk in an individual position may be less than 10%, you could still lose more than 10% because one action could cause several positions to go down at once.
The best defense against is diversification. Invest in different types of securities that respond to different market conditions.
Limiting your risk in this way can reduce the chance of massive losses, while leaving you with plenty of opportunity for upside.
Many people do this for a variety of reasons. Don’t be one of them.
Why do people add unnecessary code? It can happen for several reasons.
Sometimes it’s a fun bit of extra stuff. Avoid this. Write code to create business value, not for your own amusement. If you have that kind of itch, start a side project.
Often you will see developers writing code in anticipation that it may need in the future. Don’t do this. Only code to the current requirement. Most of the time, anticipatory code goes unused. YAGNI - You Ain’t Gonna Need It.
For some, it is easy to add a little extra code rather than ask if it is really required. Please, if you’re not sure about the requirement, you’re not talking to your business partners enough.
Occasionally a programmer invents extra requirements that not documented or even desired. And the requirements turn out to be bogus. Work with the business and meet their needs, deliver working software that adds business value. Everything else just causes problems.
Sometimes the problem with a complex code base is that there is simply too much code there.
There may be code that was created as a spike, to explore ideas, or to support business functionality that is no longer used or wanted. This code should be deleted. Leaving it in place only confuses the reader, and worse, may give other programmers the impression that the code actually belongs there and should be used.
Other code may be horribly complex and could be refactored to a simpler solution. Add five lines so you can delete twenty.
Don’t make things more complicated than they have to be. You’ll be amazed how often stuff gets over-engineered with highly complex code that needlessly adds confusion to a project.
Always be willing to reach out and assist those who work around you.
As a highly experienced and skilled software engineer, your value to the organization will rise if you can do more than simply be awesome. If you can make people around you awesome as well, your value starts to be come a multiplier.
Everyone (even you) needs help from time to time, even if they don’t realize it. When you see someone struggling, reach out and assist. Examine their problem and provide your viewpoint, how you would approach the task. In a diverse group, each person brings a different perspective to a problem, and thus you may shed some light on their problem by discussing things they may not have considered.
Sometimes just being a sounding board to allow a person to bounce various ideas is all that is needed. Other times, you may need to get down and dirty and do some pair programming. The important thing to remember is that the delivery of software is a team effort, and thus the team’s performance is often measured at the team level. If you are supporting the whole team, it will do better, and achieve greater results.
On the other hand if everyone focuses on their own thing and never helps each other, it will only lead to greater problems down the road.
Anytime someone has to type data in a field, bad things can happen.
This occurs in many places. During software development, a transcription error can occur when copying data and formulas into the code. Errors can also happen when copying logic from a whiteboard sketch or other diagram. One must always be careful here, and having good test cases with accurate examples is a must.
For the user, errors can easily occur when they are entering data into fields. Here, you need to add sanity check to the inputs. An SSN should have nine only 9 numerical digits. A phone number should not have letters. Date of birth should not be in the future.
Where possible, you can have the user select from drop down lists to limit options and reduce the chance of error. Alternately text boxes can checked against lists of known good values, if the drop down would be too long (like in the case of state codes).
For more complex fields, auto-complete against a searched table may work. In other instances, a complex regular expression will do. But the more you can avoid a user accidentally typing bad data, the more problems you’ll avoid.
Classes, methods, objects, data elements - please be consistent and predictable.
Establish some good naming conventions for your team. Follow the conventions always.
If you are working with a framework, then follow its conventions where possible. This will benefit you greatly when you add people to the team who have worked with the same framework at their previous job.
With the right conventions, everyone should know what the obvious name of a new object should be. There should be no surprises.
It should also be immediately obvious what the name represents when you encounter the name in the code.
Following this behavior accelerates development and reduces bugs.
Simple procedures are methods on objects that perform some kind of operation on the object. In those cases, the verb alone is good for a name, as it describes the action.
Say you have a Document, and it needs to print. What could be clearer than calling “document.print”?
More complex actions require an additional object. Say you have an object Soup, and you want to add Salt to it. Would anyone object to “soup.addSalt”?
Too often people complicate things. “soup.addIngredient(type flavoring, name “Salt”, measuredBy “pinch”, amount 1)” sounds horrible. Good luck if you have to expand on that.
It is extremely common for investors to find themselves in a difficult position and hoping a stock will recover. Maybe some bad news came out and the stock collapsed and continues to head downward. These desperate investors cling on, or worse, add on, to a position, hoping it will rise again back to where it once was.
Of all the tools in your tool chest, hope has no place in investing. Abandon it.
Remember, a company that doesn’t make enough money to cover expenses and debt payments will soon see its stock go to zero. Any stock that has fallen 50% can fall another 50%. The only true floor is zero.
Never rely on hope. Stick to the fundamentals. If the fundamentals have changed, then it may mean the stock is not worth owning - at any price. In those cases, sell. Get out now. Take your losses and move on.
You can’t always be right. The key to success is minimizing the damage when you are wrong. Use all available information. Examine fundamentals. Read analyst estimates. Look at charts. But hope? Hope is for suckers.
Function names should not be vague. It should be immediately obvious what you’re going to get when you call the function.
A function is a method that takes zero or more inputs and returns an output. When the output is an object in the business domain, it’s generally a lot more useful than when it returns primary types.
Say you have a function that takes zip code as an input and returns a list of nearby stores. If you named the function “getLocations()”, it is rather vague. What locations? How do I use them? What kind of object am I getting back?
On the other hand, “getStoresNearZipCode(ZipCode)” gives you the idea that it is returning an array of Store objects. It also points you in the direction of passing a zip code object as the argument.
This type of thing may seem like a trivial issue, but it greatly increases the speed of development and improves the understanding of the code by others.
If you have a class with a few methods but no data elements, it is probably better implemented as a method in another class. After all, without methods, what does it really represented?
Occasionally you’ll see these things, such as a Calculator class, that just consists of complex logic for performing some calculations. Of course, this begs the question, calculations on what? And as soon as you figure that out, you may wonder how that thing is modeled, and whether these calculations should live closer to that object.
These classes are often named after verbs.
In another example, take a class named “Shipper”. Its job is to ship something. Ship what? An order. Ah, it’s an OrderShipper. Or wait, maybe ship() should be a method inside the Order class. So my_order = new Order(”pair of shoes”); my_order.ship(”123 Mockingbird Lane”); and so on.
gummygunk
kianamaiart
blakekathryn
gracieabrams
2087
turnnoffyourmind