Source: Stackoverflow As a developer, you will hear many different theories about what code should look like. Some people believe that the fewer lines of code an application has, the easier it is to read. But this is only partially true. I prefer to evaluate code quality using the following criteria:
The code should be consistent, informative, and well documented.
The code should use stable, modern features.
The code should not be unnecessarily complex or broken.
If you decide to reduce the number of lines of code at the expense of one of the above criteria, this will become a problem. Do not do that.
Reading someone else's code is difficult
Indeed, the ratio of time spent reading and writing code is more than 10 to 1. But you can’t do without reading other people’s code. You will have to read someone else's code. And the sooner you improve your skills, the better. Try studying other people's code using open GitHub repositories. You can practice at any time: just find a project that suits you and delve into every line. Another way to improve your ability to read other people's code is for you to start copying the style. When you write code in someone else's style, it not only improves your reading skills, but also makes the code more familiar to you. Give it a try.
You will never write “perfect” code
I was a solo developer for four years before I started working in a team. For most of this time, I believed that any experienced programmer wrote perfect code. In my opinion, learning to write perfect code is only a matter of time and effort. But when I joined the team, it became clear that no one writes “perfect” code. True, the code that was ultimately included in the system was almost always “perfect.” Why did this happen? It's all about code analysis. I work with a team of truly brilliant engineers. These are some of the most competent, confident programmers money can hire. But each of them (including me) would have a real panic attack if anyone ever suggested including untested code in the application. Even if you think you are the next Bill Gates, you will make mistakes. I'm not even talking about logical errors, I'm talking about typos, missing characters. Things that your brain sometimes just doesn't catch. Things that can only be noticed with fresh eyes. Strive to work with people who are attentive to detail and willing to critique your work. It will be hard to take criticism at first, but it is the only reliable way to improve the quality of your code. Do your best not to get defensive when reviewing code, and never take criticism personally. You are not your code.
You shouldn't write code 8 hours a day
No one can tell you exactly how much time a day they spend writing code. But in reality, few people write code more than 4 hours a day. People who disagree with this are either the exception to the rule or work for companies that treat their staff poorly. Programming is intense, mentally draining work. It is completely wrong to think that someone will write code 8 hours a day, 5 days a week. There will be rare occasions when you need to meet a deadline, but when I say rarely, I mean almost never. Don't let work weigh you down and force you to work overtime. I'm not suggesting that you only work four hours a day. The remaining four hours are usually best spent on things like:
learning new tools, functions, applications;
discussing work processes with colleagues;
helping colleagues who are having difficulties at work;
task planning;
code analysis;
business meetings/meetings.
I also highly recommend taking regular breaks throughout the day and exercising (at least a little). The positive effects of exercise have long been proven.
4 Ways to Incorporate Design Thinking into Your Development Process
Source Tech Beacon To create a product that meets your customers' needs, you'll have to consider what they want. If you've written an app with confusing navigation or an unnecessarily long loading interface, prepare yourself for future failure. As a programmer, you may have to delve deeper into the design of the product your team is working on. This kind of collaboration is very useful because each person notices things that the other may not notice. I offer you 4 tips on how a developer and designer can work together.
1. Be involved from the very beginning
Don't assume that design always comes first and development comes second. This may be true, but it doesn't mean developers shouldn't be involved in the design process. The programmer is able to provide important technical information about how the project can be implemented, while the designers better understand the users' desires. It is better to find out as early as possible which function is technically impossible or does not meet user requirements. If designers and developers work together, problems can be discovered and resolved immediately rather than after the design is approved. Many companies take a collaborative approach to software development. This means that team members are not just responsible for their own stage or piece of code, but take collective responsibility for everything from design to testing.
2. Learn the UX process
Those unfamiliar with UX (user experience) may not understand why teams change designs over and over again for seemingly minor details. Every step in the UX process happens for one reason: to provide the best possible experience to the user. Therefore, it is important to pay attention to creating a UX process from the very beginning. It may include:
researching the purpose of the project;
creating a wireframe - a simple design that allows you to determine the main characteristics of the product;
adding finer details to the project design, such as the user interface;
user testing of designs. This is perhaps the most important stage of UX development. This provides valuable information about the product before you spend time developing it;
Iteration: Using analysis of test results, iterate the design to improve the user experience.
Teams repeat the design and testing steps several times until there are no changes left, or as time allows. This usually means that you will have multiple versions of the design.
3. Follow the design development
It's very bad when designers create a project without consulting the developers. It's counterproductive. It's important for DevOps to set rules so that developers have access to design blueprints in easily accessible formats such as PNG or PDF. Effective collaboration between developers and designers is critical to the successful implementation of an application. Avoid blindly handing over a finished design at all costs. It is better to correct a mistake at the beginning rather than at the end.
4. Agree on at what stage the project will be shown to you
When developers are asked to create a minimum viable version of a product (MVP), they need to know the requirements for the final version from the very beginning. This is necessary to avoid problems with unjustified expectations. Designers must show both versions of the design to the developer: both the MVP and the final version. This will help implement the MVP, taking into account what the customer expects to see in the final version. When designers and developers work together, they gain many benefits. Each of them has knowledge that can be applied to the experience of the other. Developers can provide valuable insight into what features cannot be implemented in the design. On the other hand, collaboration with a programmer will relieve the designer from the need to redo the project, which, accordingly, will save time for the entire team.
As a developer, you will hear many different theories about what code should look like. Some people believe that the fewer lines of code an application has, the easier it is to read. But this is only partially true. I prefer to evaluate code quality using the following criteria:
To create a product that meets your customers' needs, you'll have to consider what they want. If you've written an app with confusing navigation or an unnecessarily long loading interface, prepare yourself for future failure. As a programmer, you may have to delve deeper into the design of the product your team is working on. This kind of collaboration is very useful because each person notices things that the other may not notice. I offer you 4 tips on how a developer and designer can work together.
GO TO FULL VERSION