Startup development projects get derailed by well-intentioned — but terrible — advice. Listed below are 6 pearls of wisdom worth ignoring.
Building quality software is tough. And sometimes, misguided insights ensure it is much tougher.
When creating quality code and building great software, it is essential to carefully plan your project and communicate well during each step of web application development and mobile application development.
Though good advice is not scarce, bad advice runs rampant amongst those lacking expertise. With this in your mind, I reached out for some fellow developers and innovators in the tech space to hear about their software development experience and asked them to fairly share the worst advice they’ve ever received. Guidelines a few of the best insights from those conversations, and my own personal “worst” advice:
1. If your change is small enough there’s no need to test.
Testing code is crucial. As Charles Kong, a Google developer, explained, “Software engineers face the issue of simply how much time ought to be used on writing tests, and some might say that with negligible change, unit tests really are a waste of time knowing it’s not at all likely to break. For me, tests should continually be written for almost any bit of code, and for a trivial change, it’s much quicker and easier to write an easy test because of it anyway. There is a constant know whenever you will make that minor spelling mistake that takes place to compile.”
Errors happen, so don’t sacrifice testing your code–irrespective of how trivial or small it could seem.
2. You don’t need to comment on well-written code.
Some say commenting is a lost cause. Actually, it’s not.
Not everybody will understand your style of writing code. Jawbone developer, Trung Le learned this the hard way. “This is inappropriate, you always need to comment your code. The reason I don’t like this advice is really because LOTS of men and women don’t read code well, hence they rely on the narrative from the comments to understand how code works.”
3. Avoid offshoring at any cost.
This generalized statement is one we often hear about foreign programmers. However, it’s a misconception, in accordance with my co-founder Pratham Mittal.
“This advice makes an incorrect generalization,” he explains. “You will find both good and bad software developers within any country. Vietnam software outsourcing and Vietnam software services have a big talent pool high in educated and competent programmers.”
4. Build on opinions or assumptions vs. measurable results.
In accordance with Ludo Antonov, Technical Lead for the Pinterest Growth Team, an engineer can be used to getting plenty of advice. But when it comes to product development, he says, “The most destructive advice is the sort that lures you into building solely based on opinions rather than measurable results. Quite often, many good engineering hours get wasted that way.”
Product development is not subjective. In fact, it’s all about results.
“At Pinterest, we’ve harnessed a phenomenally laser-focused and data-driven approach, that’s critical for the success,” says Antonov. “It’s essential for ideas to get their way into code and be tested out. However, relying on opinions alone is very risky when it comes to deciding on the code’s success, and its introduction as a lasting section of an item, which needs to be well supported over time.”
Sites with large traffic should run many experiments on subsets of their user base and optimize based on key metrics.
5. Don’t touch ‘that’ part of the code.
It’s there and it’s working, then why touch it? Well, simply because it’s running doesn’t mean it’s right. It must certanly be functional. And because another person has written the code doesn’t mean you can’t handle it. Comprehending someone else’s code is the potency of a good developer, explains Adnan Ali. You must be fearless.
Being the lead software architect at Financeit, Ali has received plenty of advice. “Nevertheless the worst piece of software advice I’ve gotten is ‘Don’t touch that the main code. Nobody touches that the main code!’ It absolutely was some core the main system and the developers were afraid to touch it. Ignoring the advice, I walked through it line by line so I could know what it does. Based on that understanding, I made a big change that got us a 20% performance gain on each web hit. Reading and understanding other people’s code is among the main skills for developers,” he says.
6. Don’t worry about planning.
These are some classic types of why you ought to question the advice you receive. But as for me, the worst advice I’ve ever received is: Don’t bother about planning. You’ll determine everything over the way. Just start writing code.
I believe planning is really a critical phase in any development project. While you don’t have to plan out every single minute detail, mapping out your product and prioritizing features is essential before writing code. The majority of the time a team will believe all features are absolutely essential. Without prioritizing and separating out features into different versions you increase the total amount of time and money invested into your first product. Instead, you ought to concentrate on building your core necessary features and getting feedback from your own end customer.
We all get plenty of advice and should always listen as to the folks have to say, but we’ve to critically review the feedback we receive and experiment with various strategies.
Where do you receive your software advice from? What was the worst advice you’ve received? I’d love to hear it.
Source: S3 Tech Blog
