Articles Uncategorized

24 ways for being productive with big code base

In this article we will take a look at some of the guiding principles which are beneficial while working with large code base.

The whole idea of this post is to collect and come up with a checklist of significant approaches and ways to deal with large and legacy code bases.

The readers are welcome to share more tools, methods and approaches in the comments section below.

1. Onboarding Documentation

Ask if there is onboarding documentation, or someone who can give you a high-level overview of the codebase. Typically finding a person with a lot of context on the code is the fastest and most thorough way to understand the responsibilities and layouts of a codebase. Ask if they can draw an ER(Entity Relationship) diagram, it’s extremely valuable documentation for any additional developers.

Show me your flowcharts and conceal your tables, and I shall continue to be mystified.

Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.

— Fred Brooks

2. Read Documentation

Read all the documentation possible, especially design documentation. This should hopefully give you some clues as to both function (what) and purpose (why). The discussion around this will also introduce you to the major players in the architecture of the codebase.

Documentation is the castor oil of programming.

— Gerald Weinberg, The Psychology of Computer Programming

Note this does not necessarily mean formalized design docs, it could just be searching for any README’s or relevant wiki pages. You’re just gathering threads at this point, and documentation tends to be a lot more compact and easily digestible than foreign code.

3. Look at the models

Look at the models – there will be compact representations of data at some point. This gives good insight into the shared language of the code and can give a lot of clues about how things are done. They also tend to be a lot more human-readable than other pieces of code, so this is a plus.

The architectural model provides a Gestalt view of the system, allowing the developer to examine it as a whole.

— Scott Ambler, Agile Modeling

4. Find and Skim the largest files.

Typically these files perform the majority of the work, have the most responsibility, and introduce most bugs. Knowing roughly where the major players are and what they do makes it a lot easier to read any individual file.

You need to be fully aware of the presence of any God Class or components in your codebase which pose a serious threat to the long-term health of your product.

5. Run the application

Run the application, find some small behavior (a single, simple endpoint) and debug it. Step through the application code so you can see how a particular request flows through the system. This can show you how a lot of different concerns within the code are tied together and also ensures that you’re set up for both running and debugging the codebase.

6. Don’t plan a full rewrite

Don’t plan or do a full rewrite – it’ll almost never work. Jeremy Burton has this wonderful postdiscussing the social and economical impacts of code re-writes.

When you inevitably come across a trade off, choose the one which is easiest to change later. Everything else is just noise. Large changes in legacy systems often suffer from the second system effect among other problems.

7. Learn the tools

Learn and use tools to automate the build system and quality assurance (JenkinsSonarqube,DockerGit, etc.)

Great tools let us do the impractical and the impossible. They give us super powers. The goal should be to know your tools so well that you can focus on the work at hand, without having to think — they should be second nature.

8. Sharpen the saw

Sharpen the Saw means preserving and enhancing the greatest asset you have–you. It means having a balanced program for self-renewal. It is the mindset to seek continuous improvement and renew yourself professionally.

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.

— Abraham Lincoln

Take the time to improve your skills and the skills of your team (coding dojos, experiments). An excuse to not sharpen the saw is an excuse for failure, burnout, and mediocrity.

9. Spend time with your end users/customers

If possible spend time with the main user / product owner (especially in peak periods). You’re blessed to have users, who understand your system.

The team is actively encouraged to spend time with actual customers to learn more about their needs. A developer may spend time observing real users and come away with brilliant insight into what is most needed.

10. Focus on cross cutting concerns

The crosscutting concern also known as system-wide concern is a concern which is applicable throughout the application and it affects the entire application. These are the concerns representing functionalities for secondary requirements. These are typically implementation details that need to be kept separate from business logic. Do refactoring and first focus on cross cutting concerns (APIs, translations, caching, logging, database, etc.)

11. Migrations

Migrate things to well tested isolated APIs (e.g. use REST / Graphql APIs with new endpoints in the frontend and try not to use untested code for these APIs). It is always a good idea to have a strategic plan for migrations in your development roadmap. It could be every 6 weeks or 6 months, but it should be done at regular intervals of time or else you will be incurring a large amount of tech debt in your codebase.

12. Move fast and break things

Don’t be too backwards compatible (move fast and break things) This way of working usually emphasizes testing out new ideas, iterating quickly based on data, and aiming for more frequent points of learning. Allen Yang exhaustively discusses the pros and cons of this approach in this Forbes article.

13. Get the team on board

If there are multiple people you need their buy-in and support for whatever approaches you want to do

14. Plan for “health by a thousand small improvements”

It will be an iterative approach and you will refactor as you go.

15. Don’t assume different = bad

People might have done differently, consider using their approaches. You might do it differently. But it’s better if you keep a consistency within the codebase. In codebase management consistency trumps cleverness.

16. Create space

Consider introducing a Fix-it Friday where everyone can work on little improvements. Think about conducting a bug-bash in your organization, at regular intervals of time so that it automatically creates a platform where all the developers, testers, program managers, usability researchers, designers, put aside their regular day-to-day duties and “pound on the product”.

Because each person will use the product in slightly different (or very different) ways, and the product is getting a great deal of use in a short amount of time, this approach may reveal bugs relatively quickly.

17. Create a Non-Blame culture

Stuff will break if people risk improving things. Avoid blame shifted to them. If bug trackers ping individual people consider pinging the whole team instead.

If you get your ego in your way, you will only look to other people and circumstances to blame.

Jocko Willink

18. Consider automation

While “development automation” is not a commonly used and recognized term of the software development industry, business people normally use it to refer to “anything that can speed up the development process and allow the organisation to bypass most, if not all, of the software development process, jumping from a simple business-level wish list to a ready-for-the-market product (writing as little code as possible and hiring as little programmers as possible)”.

Any technology/methodology that can reduce software development to the most complicated thing the average business guy can understand.

Here are some examples of development automation:

  • Automatic update of dependencies
  • Automatic build process
  • Automatic checking of style rules
  • Automatic execution of unit tests with every build
  • Automatic update of code-generated proxies
  • Automatic creation of deployment packages
  • Automatic configuration of target environments
  • Automatic deployment to development or QA environments
  • Automatic computation of metrics, such as Code Coverage
  • Automatic smoke tests
  • Automatic generation of release notes, or at least of the bug list that goes in the “Fixed in this build” section

19. Start with the tests

This one is the most annoying, but worth doing. Whenever you improve a feature a bit try adding a test. Often in legacy apps there are no good tests. A lot of people recommend writing a test suite for the whole app before you do anything. If you are lucky enough to do this try it. The iterative approach more realistic as you can also do feature work while refactoring.

When doing tests focus on integration (vertical/functional/etc) and not unit tests (unless the “unit” contains critical or complex logic). Your goal is to know “that you broke something” – you get by if you don’t always know “what you broke“.

Write automated tests (unit, integration, acceptance) for existing code where ever possible. Write at least unit tests and integration tests for new code.

Make sure you have development and test environment available, including data transfer from production to test.

20. Acknowledge tech debt

Not everything needs refactoring. If it’s not critical and nobody needs to touch it consider acknowledging it as tech debt. Add larger notes above the problematic areas and explain why you aren’t refactoring it, explain things worth knowing to understand the code better, etc. Whenever you leave comments remember that comments should explain “why” not “what” the code does.

21. Read a lot of code

Spend time reading code in the codebase even if it does not seem to make sense, even if you don’t think you’ll need to know that part of the code. Keep reading until it starts to make sense. The trick is to just read. You can even avoid tools that automatically navigate the code because you will know eventually where things are.

22. Debugger is your BFF

The first and the foremost task while working with existing code bases is you need to get debugger working. Nothing can explain the processing workflow better than tracing the execution.

Get familiar with your debugger. You may be surprised by how deep in a call stack a bug can live. It will also make you intimate with the different ways your codebase is orchestrated together. Also having any kind of schemas, protocol definitions and tests can help grasp whats happening in the system.

23. Use the boyscout approach

Clean where other left dirty stuff. Sure, many here would argue that “never touch a running system” is a gold rule, but what if the running system is running in the wrong way?

The Boyscout rule

Always leave the campground cleaner than you found it.

If everyone attain her/himself to this rule, there wouldn’t be what we call innovation.

24. Don’t try to fix the pile of mud

Complicated software are infections of a complicated business requirements. When something is a pile of mud, don’t try to fix the mud.

Fix the business requirements until it get easier to handle. This also leads, most of the time, to a massive reduction in messy code bases.

At this point you should have a fairly solid understanding of at least the most critical points of the codebase, and also be set up to run and debug it. You should also have at least one or two points of contact to ask questions. This gives you a good framework for figuring out how to modify the codebase moving forward.


15 Fabulous ways for Technical Leaders for making more time in a day

15 Fabulous ways for Technical Leaders for making more time in a day

In this article, we will be looking at fifteen ways of making more time for technical professionals, leaders and managers in a day. You should keep the following in mind if you want to have more control of your time to carry out some of the most important tasks for yourself at the same time keeping people around you happy and sane.

When you sit with a nice girl for two hours, you think it’s only a minute. But when you sit on a hot stove for a minute, you think it’s two hours. That’s relativity. – Albert Einstein

You don’t find time, you make time. You can make time for whatever you really want to do, so if you don’t find time for it, perhaps you don’t want to do it. Perhaps you should find a way to do it.


1. Don’t do things you’ve already assigned to others, even if you must let them make mistakes.

Don’t redo work you’ve assigned to others. When you do, you pay several times for same work: first with the time to explain it to them, then with the time to take it back without hurting their feelings (which really won’t work), then the time to repair any damage they’d done, and finally the time to do it yourself.

Whenever someone showed signs of making a mistake – even of uncertainty – you should not grab the work back under the pretense of teaching them something. You must let them make mistakes. It’s part of the price you pay, and it’s more efficient in the long term.

Don’t redo work you’ve assigned to others.

This means that you should not interfere with other people’s job once you have given them the control to do that in their own way. Even if the person doing the job is making mistakes you should gently point them out to him and take corrective actions as soon as possible. The key here is to enable people to take responsibility for their work without worrying about the unnecessary administration madness.

You need to remember that you will have to work with people and they’re not going to be perfect; there will be times when they will let you down. They’re going to make mistakes, and if you demand perfection from them, you’re going to be hard to work for. The good people will leave. Therefore you have to overlook your own and other people’s imperfections. When you overlook, you’ll be able to overcome.

2. Avoid administration like the plague

Choose your own priorities and don’t wait for a crisis to organize your activities. When you are appointed as the leader of a group, not only do you have to organize time for other people, but even worse, you have to organize it for yourself. The true test of a leader is what she does when there’s nothing to do.

Choose your own priorities and don’t wait for a crisis to organize your activities.

3. Don’t waste time trying to prove your competence.

Avoid trivial technical arguments to prove your technical superiority. As your career advances you have to let go of certain things. Arguing over minor technical points indicates you’re still holding on. When you are really technically superior, there isn’t any long argument because you can convince people swiftly and easily.

This is one of the big time wasters of amateurs fighting for their competence in one of the many unimaginable ways you can think of. The professionals know that there is always someone better than you at any given point of time and they don’t willingly participate into heated discussions or arguments vying for dominance and power.

Avoid trivial technical arguments to prove your technical superiority.

Remember it is the Dinosaur Brain that is working for you, when you are trying to get into an argument with someone as pointed by Albert J Bernstein in his seminal book, The Dinosaur Brains.

Seeing someone else lose his or her temper or begin an obvious power play can pull you right into your Dinosaur Brain too, leading to what is unscientifically known as the Godzilla meets Rodan effect: There is a great deal of sound and fury; buildings shake but little gets accomplished.

4. Don’t waste time arguing about wasting time.

Whatever you can do, or dream you can do, begin it. Boldness has genius, power, and magic in it. Begin it now – Faust, Johann Wolfgang von Goethe

5. Pay attention to what you do when there’s nothing to do.

Your attention is in short supply. There is only so much you can pay attention to, and there are so many things that compete for your attention daily.

Generally, it’s easy for us humans to divide our attention fecklessly such that nothing receives our full attention and so nothing effective gets done.

Beware idle-loop chatter

Competition for your attention isn’t always external, either. For instance, your logical brain CPU has a sort of “idle loop” routine. If nothing more pressing is commanding your attention, your idle loop will chatter away on some low-grade worry or indolent concern, such as “What’s for lunch?,” or replay a traffic incident or argument. This of course then interferes with intuition, problem-solving and creative processing, and you’re back to working with half a brain again.

You might hear yourself often saying, “I’d love to, but I don’t have the time.” Or some new task comes up at work, and you think you just don’t have the time to attend to it. It’s not really time that’s the issue. Time is just something you allocate. It’s not that we’re out of time; we’re out of attention. So instead of saying you don’t have time, it’s probably more accurate to say you don’t have the bandwidth. When you overload your bandwidth— your attentional resources—you’ll miss things. You won’t learn, you won’t perform your work well, and your family will begin to think maybe you have a brain tumor or something.

If you’re really paying attention you can accomplish marvelous things. Paul Graham, in his book Hackers and Painters: Big Ideas from the Computer Age, suggests that “a navy pilot can land a 40,000 lb aircraft at 140mph on a pitching carrier deck at night more safely than the average teenager can cut a bagel.”

The teenager’s mind is easily distracted, and that doesn’t seem to be one of those things that gets any better as you age.

The pilot, on the other hand, is really, seriously focused. In that situation, a moment of indecision or error, and you’re spectacularly dead. We need to develop that sort of concentrated focus but without the inherent risk of incineration.

6. Get at least two for the price of one.

This does not necessarily mean that you should have good negotiating skills so that you can get two apples at the price of one. What this means is that, you should be doing your work as efficient as possible, so that you get two tasks done at the time of one. This calls for an incessant increase in your productivity to get the maximum effectiveness of your work or job. And in order to achieve that, you should be continuously striving for the improvement of your skills and capabilities for the job.

The Swiss are not just efficient, they’re doubly efficient. Rather than ask for riches, the Swiss asks for something that will produce income, something that will continue paying in the future, even after God is no longer around to create or buy milk.

And like the Swiss, successful problem-solving leaders seem able to create situations where they get a little more out than they put in. Yet at the same time, these situations seem to benefit everyone involved; nobody gets cheated.

7. Act as review leader.

You can keep up with what’s going on technically by leading technical reviews for other teams. It gives you a chance to practice your people skills. At the same time, you get the benefit of hearing your best technical people trade views about the very projects you’re working on now.

8. As as editor.

You can also review, but in a different way. You can read technical papers for journals and act as as reviewer or editor. It forces you to dig into some good technical content, and you get lots of brownie points with management for doing it. It also improves your own writing skills.

9. Be a tutor.

We have all these online technical courses on the internet such as video tutorials, webcasts and podcasts, but everybody seems to hate just sitting in a little room and watching them. You can volunteer to tutor people who were taking the courses. It sharpens your communication skills, your one-to-one handling of people, but even more, it gives you a chance to really learn the technical material in depth. You get far more out of it technically than any of the students do.

10. Coordinate a speaking or training program.

Get yourself appointed as coordinator of some visiting speaker programs. That means you get to attend every speech, seminar, or class that’s done by an outside expert, if you’re interested. But better than that, you get to spend time with these visiting experts, time when you can discuss any subject you want. It’s like having private tutoring from the smartest people that money can buy. And most of the actual coordination work can be delegated to someone else.

11. Use your car pool.

You can also make use of your company car pool to keep up technically. You can spend your commuting hours with your best technical people. All you have to do is keep the conversation steered away from other subjects.

12. Share the reading load.

You could never keep up with all your technical reading until you and your peers realize that you have the same problem and decide to share the load. Each can read something and report on it to the others. Sometimes, the first reader can tell them to skip half the material. Sometimes they can skip it all. You get multiple times the coverage now for the same effort.

The real voyage of discovery consists not in seeking new landscapes, but in having new eyes. – Marcel Proust

You simply cannot read every book that has ever been written in the history of mankind. Your lifetime will not permit it to do that even if you spend all of your awaking hours by just reading books. What is the point of reading all that stuff if you don’t have time to discuss it with your friends, colleagues and other fellow people to get the full understanding or what you have read.

It is the multitude of perspectives about a thing or concept that matters the most about knowledge rather than a single narrow-minded view of things. It is only through that you get far ahead in time.

13. Have a good lunch, but a creative one.

14. Listen to what other people have already learned.

15. Let other people show you how smart they are.

By giving other people some time and space, you are building an organization of trust by giving them respect through listening and learning from their experiences is one of the most time savers in life. You can easily lean on someone trust-worthy for making trivial decisions at the right time since the other person shares the same interest with you , this is both mutually fulfilling and productive.

Resources Wallpaper

Free Wallpaper Pack – Random Green Blocks

Every week, we provide our readers with some free and high-quality graphic design resources such as icons, stock images, and wallpapers to add some extra flare to their projects and artworks. Today we are giving away some high quality abstract patterned wallpapers for free. The pack contains high quality wallpapers for various standard available monitor sizes, for iPhones and also for iPads.

Simple, Free Image and File Hosting at MediaFire


Simple, Free Image and File Hosting at MediaFire


Simple, Free Image and File Hosting at MediaFire



Inspirations Productivity

Productivity Mania

This is a weekly series of posts in hangaroundtheweb which provides you with a fresh dose of hacks, tips and tricks from the internet on: simplicity, health & fitness, motivation and inspiration, frugality, family life, happiness, goals, getting great things done, and living in the moment.

An Autodidact’s Schedule

It’s Not Too Late to Change Your Habits

How to Stay Alert & Refreshed: 6 Ways

How to Go Paperless: 8 Ways

Crisis Cruising – an Extreme Sport?

How to Keep Motivated During the Dog Days of Work

The Benefits of Taking Quick Getaways

Why Getting Things Done is the Best Productivity System

How to Use Pinterest to Get Productive and Stay Motivated

How to Hack Your Weekend

7 Tricks to Write Faster, Better, And More Insightful Articles Right Now

How to Turn Your Ideas into Life Changing Actions

11 Underrated Ways to Improve Your Sleep and Get You Focused, Happy and Massively Productive

How To Make Friends And Keep Them

The Most Overlooked Secret to Dealing with Life’s Problems