The recent shift to working from home is likely to continue for a long time, with the return to the office unlikely until march at least.
In fact, it doesn’t really matter where the programmer works, just where the code is typed.
Time is fast. I’ve been wanting to say something since I started working at home, but I haven’t written anything yet. Now it’s been more than two weeks, and it’s time to write something.
First, there are more meetings than before
When you work from home, your days are filled with conference calls, video conferences, voice conferences, etc.
In the office, meetings are only necessary for major events such as requirements reviews, design reviews, and morning project meetings or weekly team meetings.
But working from home has dragged me to meetings every day, and here’s my schedule for a particular day:
From 9 in the morning to 8 in the evening, there are meetings all the time, and sometimes many meetings overlap.
This is where the benefits of working from home come in. I can attend multiple meetings at once. Nail video conference one, cell phone conference one. I ban my mics when I’m not needed.
For example, in some meetings, I’m just in charge of bringing the relevant people together, discussing, and finally getting a result, I just send an email. In this case, I don’t need to speak, I just need to listen.
In other meetings, such as technical solution review, only a small part of the meeting is relevant to me, so I just need to open the mic when discussing this part.
If the meeting is held in the company, it is impossible to hold the meeting at the same time, which greatly improves the efficiency of the meeting.
Two, cut demand cut even harder
One change I didn’t expect from working from home, for better or worse, was that I hacked my needs even harder!
I’m sure many front-line developers, like me, get requests from a variety of people every day.
The odd requirement makes us laugh and cry, but most programmers will find a way to solve this requirement after some psychological struggle.
In fact, all requirements need to be solved, which is true, but my advice to you is to solve the requirements with your mouth first, and then solve them in code.
During the two weeks after I worked at home, a project I was in charge of was in the phase of joint investigation, but I still received some demands at this stage, some of which were the demand changes and new demands proposed by the product manager, and some of which were the technical requirements proposed by the partner. Interface synchronization, one more system interaction, even the format of ERROR_CODE, and so on.
Since the project I am in charge of is a new product launch, it needs to be launched as soon as possible to receive user inspection, and there is no need to be particularly complicated at the very beginning. Therefore, for these needs, the current state is can chop chop, can not chop first with the simplest way to go up.
Therefore, in the past two weeks, I found that I was cutting demands more and more. Once, another student in my team asked me about the status of a document. I casually asked why I was doing this, and he said that the product manager asked him to fulfill a small demand.
When I got to know, I put him on a conference call with the product manager, and I moved to move, moved to reason, cut everything that didn’t make sense, and improved everything that could be optimized.
Originally need 2-3 systems cooperation to achieve a query function, after adjustment, become only need to query a system can be realized. This reduces system interaction, reduces risk, and reduces user understanding costs. Why not?
I always believe that the programmer who meets all the requirements must not be a good programmer! but
Some needs, always someone to stand out first cut! Even if it doesn’t, I think it’s good:
1. It allows us to understand what is behind the requirement. There must be many reasons why we didn’t cut it in the end. Only in the process of discussion can we understand the reasons behind these more. Otherwise, you may end up implementing a feature that you think is “crap,” but there may actually be some reason behind the requirement that you don’t understand. Such as compliance risk, legal risk and so on.
2. Express our attitude. I think, as a programmer, attitude is very important. For example, some disgusting or need, we can be “under pressure” to achieve, but we still have the right to express our “disapproval” attitude. And the process of expression is also a process of setting up your voice.
I had many considerations for cutting down on demand, but reducing workload was definitely not the most important. In recent days, I have summarized the requirements, using a few very simple architectural design principles:
1、Keep It Simple ， Stupid
2, the Open/Closed Principle
3. Single Responsibility Principle
4, and Minimize Coupling
5, Avoid Premature Optimization
Simple point, whether system function, or system code, the most afraid of is complex. The more complex a feature is, the less users like it, so if it’s complicated, it’s probably junk.
System implementation is also above, if a function, implementation is very complex, that is likely to have a lot of problems. The best way to solve these problems is to reduce complexity in advance.
In addition, to clearly understand the system boundaries and relationships, there may be 100 ways to implement a feature, but who should implement it? How can coupling between systems be reduced? How can it be implemented for greater scalability and maintainability? These are all things to consider.
It is also important not to optimize too early in the process. Remember: Done is Better than Perfect,
Some of the requirements we deal with on a daily basis are business and some are technical. So, what are some good principles or methods to refer to? What can and can’t be hacked? How do you cut it?
I’ll write a detailed methodology on these issues later, combining examples from my work on how to cut demand. If you have better suggestions, or are interested in this topic, you can leave a message to me, welcome to discuss!
May there be no change in demand in this world! ~
