Is it possible to work as a programmer, but not estimate the deadlines?

Question

Regular Expressions

I'm probably a good programmer, but it annoys me when they ask me about deadlines.
First, it is very difficult for me to evaluate. The timing question makes my brain freeze or go into endless recursion. My brain spends more resources on it than on the development itself.
Secondly, it is psychologically difficult for me, I'm afraid to call too short a term, not meet the deadlines and I will be fired. Well, or on the head will not pat. I'm afraid to give too much time, because it will be too expensive and the customer will refuse. And others will think that I am such a brake.
In general, I have a weak nervous system.
As a result, I write code and all the time I am afraid that I will not be in time.
I want to program and not think about anything.
Here I am writing my open source project, there is grace - you don’t need to evaluate anything, you invent it yourself, you implement it yourself, no one is above your soul. But you won't earn it.
How to be?

Answer 1

For me, logically, there should be symbols before the loohahead

well, let's assume that there is a "symbol" )
"beginning of the line" ^
3 "looking forward": (?=.*\d)(?=.*[a-z])(?=.*[A-Z])
(?=.*\d)- there must be at least 1 digit ahead of the beginning of the line, no matter where exactly
, first comes .*, where .- any symbol and and quantifier *0 or "many" times, and then the number \d
next forward looking
(?=.*[a-z])- necessarily 1 small letter of the Latin alphabet
(?=.*[A-Z])- necessarily 1 large letter of the Latin alphabet

And the second question. Why does this regexp work if you swap such characters:
abC123, Cab123, 123Cab - that is, the order of uppercase lowercase and numbers is not important, but lookahead groups go in order

here "looking forward" goes just from the beginning, the order is not important, it is more like checking for the presence of a
particular character
https://regex101.com/r/IcUFYB/1 -", then in this case you will not be embarrassed by the regular season? :) ps at one time I really couldn’t delve into all these “forward/backward looking ” p.p.

Answer 2

1. NOT EVERYWHERE there are deadlines. Look for a job where deadlines are not required. There are plenty of such places. As a rule, these are long-term projects owned by the business, and not shitty web studios, stamping to order.
2. Deadlines can be voiced if you write something that you understand, the task is transparent or typical. There are tasks when deadlines are out of the question - for example, support / analysis of someone else's code. In principle, there can be no deadlines for such tasks.
3. Once I arrived with a breakdown of the car to the master-private trader. I say - that's not working. Timing? And he answers me - but I can not say. How do I know what's broken?
This I mean that even in such a topic as auto repair, where it would seem that everything is clear and everything is done according to the established scheme, the deadlines are extremely undefined.
4. If you are required to meet deadlines, then you are doing something wrong or working somewhere in the wrong place. You can talk about the timing in construction, where the laying of one tile STANDARDLY takes N minutes and you have to cover the floors of 30x40 meters. Then the timing is correct. There are no deadlines in IT. Those. the performer should not think about deadlines. It's none of his business. Management should give time with a margin and not torment the performer.

Answer 3

The most important thing in this industry is not the quality of the code, but the timing. The entire industry is driven by deadlines. And no, such an employer who will give a lot of time to implement the feature. Any employer is interested in extracting maximum profit with minimal investment (i.e. saving the development budget).
You'll have to learn to work with it and live with it. No other way. This is the main skill.
On the other hand, it is not so difficult to estimate the time that you will spend on implementation:
1. When they ask "how much time will it take" - always answer - give 10-20 minutes for an estimate, I cannot weigh it without counting.
2. Break the task that you were given into sub-tasks. Usually it turns out - processing / creating some form, adding a small calculation and the like. That is, in fact, one task in its vast majority consists of small sub-tasks.
3. Increase the timing by ~50% (+/- 20%). For example, it will take no more than 30 minutes to create a CRUD form, and you name an hour. And other subtasks in this spirit. As a result, even if you miscalculated somewhere, you have insurance.

Answer 4

Your problem is quite typical in fact :) These are not some individual features, it's just that many are afraid to admit it to themselves.
For example, within the framework of classical scrum planning, the team evaluates individual features or tasks by the whole team, and not yet in man hours, but in abstract units, which are converted into man hours based on the speed of people's work before. Whole system.
This is done because in development the time of most tasks is very difficult to estimate adequately. Most estimates are just numbers from the sky. Plus, real time usually "strives" to the planned one. That is, if you do the work faster, you will stretch it so as not to do it ahead of time, so that people do not think that you are deliberately giving high estimates. If you don’t have time, then you will work like papacarlo on weekends, ruining your health and the quality of the product that you are developing.
The problem is that timing is very important to a business. And if the manager cannot estimate the deadlines, then he will strive to delegate this assessment lower in the service hierarchy. At best, the final link will be a project manager who will work with the team on time estimates, taking responsibility for them. At worst, he will try to avoid this responsibility by delegating the assessment of the timing to each individual developer. Their estimates will certainly be adequate in a very small number of cases. Nevertheless, due to the "strive" of real terms to the planned ones, an illusion of process controllability will be created, which is beneficial to everyone in this chain, except for the developer himself and the product that he does (read the customer).
At the same time, such deadline estimates begin to look like tools to motivate people to work, replacing traditional motivation tools: teamwork, bonuses, etc. And as a motivational tool, it really works in many cases. Without canceling, of course, the usual effects that are harmful to you and the project as a whole.
What to advise is a difficult question. Well, to work on serious projects, of course, with professional people. There are fewer such problems.
And of course, learn to evaluate. After all, your worries are caused by uncertainty. You just don't know how to say the correct number. Of course, no one really knows, some just try to convince themselves that they do. However, you can get closer to reality.
A systematic approach makes a big difference.
And of course, the classic trick with the ears: laying down risks. Just factor in the risks by adding time, being brave enough to say the big number. And if you actually do it faster, consider that the risks you considered simply did not happen. This will be very clear to your manager.

Answer 5

Take tasks where deadlines are not critical, for example, I order everything in advance or some minor things, and I generally don’t care how much a person will do.
Name the period in advance 2 times more, and you will lose some of the customers, but with those who remain, you will absolutely calmly work in a mode that is comfortable for you.

Answer 6

Estimating the time for a task is quite a common procedure, and not only in IT. So it's better to learn how to do it, since most often an assessment is required.
If you have several years of programming, then you are able to plan work on a task from start to finish, breaking it down into smaller ones. Evaluate each small task and add up. Again, most often it happens that you have met a task in one form or another, maybe some of its parts have met, build on them. And always take a margin of + -10-20%. If the technology is not familiar, then evaluate the same task within the familiar technology and multiply by 2 - to take into account the time to learn the technology. If some stages are unclear, unknown, then discuss them separately.

Answer 7

There is a project called Fogbugz
www.fogcreek.com/fogbugz
In it you can set tasks and indicate the time of their execution. It collects information and then can give a prediction about the time to complete the task.
Based on experience, I can advise you if it seems to you that the task will take a couple of hours, and tell the customer 4 or 6. Enter your own time into the system. After a couple of months, you will have some picture of your speed.
In my opinion, it is better to increase the time a little than to do it at the wrong time. In general, this comes with experience, but it is still very difficult to estimate the execution time. Personally, I try to learn as much as possible about a task before it starts or before I submit an estimate to the client.
What else can I say - do not worry too much about the time estimate. Everyone makes mistakes, even specialists with 10-20 years of experience.
There is a slightly different approach - continuous development, in which you need to set time estimates, but it is not necessary to comply with them. Those. The developer does the evaluation for himself. Something like a personal motivator, nothing more.

Answer 8

Depends on the company and how things work there. From experience I can say that there are. Sometimes they will ask how things are at the current stage and how much is approximately left, and that's it. Only here the main thing is not to be impudent, so as not to give the impression that it could have been done faster. Look for small companies with an informal atmosphere in the
PS team

weak nervous system

I recommend Novopassit.

Answer 9

https://events.yandex.ru/lib/talks/2235/ - I advise you to watch this video. Its essence is that you need to multiply up to 2 weeks by 2 or 3, and from a month - by 1.7 and add 2 weeks.
I ask you not to take my answer with hostility, as I have no idea about your experience. Below I will describe my opinion about programming and timing.
Programming is just a means of accomplishing certain tasks. The essence of programming is problem solving. The market does not stand still, and it is critical for business to understand when it will be able to solve its problems and whether it is relevant to solve these problems in principle.
Having experience in product development, you can roughly estimate the time frame for tasks that you have already completed or that you have an idea how to do. In principle, if you work as a Junior, you can tell your manager that it is difficult for you to estimate the deadlines and refer to a lack of experience - an adequate person will understand this. If you have a higher level of responsibility, then setting deadlines is a very important part of the job.
In principle, any project can be divided into small parts. In order to understand in the future how long one or another small part will take, you can write down the exact time for completing these tasks - with experience, the time for some previously new tasks can be reduced even up to 3 times.
Of course, to break the project into small parts, a preliminary analysis is needed if this is not a trivial project. But in this case, you should be given a detailed technical task and given time for intellectual work.
If you have a weak nervous system, this is very bad for both career and professional development. This is corrected in a simple way - do not bathe and honestly assess your capabilities for yourself. The problem with the customer is not your concern if you are not a freelancer. Working with the customer and protecting deadlines are sales problems. Regarding responsibility to the manager - watch the video, the link to which I left above.
But still, setting deadlines for a programmer is a paramount task, because the profession is not limited to writing code. These are the realities of business. I hope that helped a little with your problem

Answer 10

You can take time to design, you will kill two birds with one stone, you will have a general block diagram of how and what it should look like + you can test the soil.
Let's say I do this:
I received a project, walked through the TK a couple of times, threw in a block diagram of the interaction of components.
Depending on the Framework / PL, you can immediately after the flowchart start to google packages that suit you and speed up your development.
After you have searched for the packages, you can design an EXAMPLE database structure (approximate caps because in 99% you will still change something).
All this takes different time depending on the size of the project (from 1 day to a week).

Answer 11

Is it possible to work as a programmer, but not estimate the deadlines?

No

I want to program and not think about anything.

for this you need to become a superspecialist in a narrow area and do it in time equivalent to the time spent negotiating deadlines.

Answer 12

There are millions of programmers capable of estimating deadlines. To have a fine nervous organization, one must prove one's worth. Can you show me the github?

Answer 13

I have never understood developers who, at least roughly, cannot set deadlines and estimates.
Even this example with a basket file of 20 tons of lines. I can estimate its analysis and understanding in about two days, if there is access to the site where this basket is used to see its behavior.
Writing additional functional to it - this is already a task to study.
If you can't evaluate in hours, evaluate in days; if you can't evaluate in days, evaluate in weeks.
Moreover, the timing and assessment are different things, so that everyone understands. I can estimate the task in 8 hours, but I will show it only in a week. This is fine.
If it is not immediately clear how to evaluate - agree on a paid diagnostics. In the same auto repair shop or office for repairing computers, they do just that and it's okay.

Answer 14

I worked in one office and they paid as much money for the task as much time was spent on it without thinking about the deadline at all. Of course, it was impossible to deal with a trifling task for a week, but there was plenty of time not to crutch, but to reach the right and correct solution. Those. you could spend a day or two on one task, other things being equal.
But in any case, there are deadlines because the person ordering the software usually does not understand anything about programming, but he wants to wait for the product to be delivered.
Using a household example, it can be explained as follows: you buy a refrigerator in a store with delivery and you don’t leave the refrigerator in the store by saying - yes, delivery takes time, so bring it in as soon as you are ready, instead of a simple question: how long will the delivery take? !

Answer 15

Practice evaluating for yourself in a relaxed way. We singled out the task, wrote down the estimated time of the task on a piece of paper, completed the task, compared it.
The skill of estimating time is being developed.

Answer 16

fix the deadlines for some work after the fact. make for yourself some kind of table, how much each type of work takes. Based on it, you can roughly estimate. +/- 25% for works for 1-3 days can be estimated. in addition, you can evaluate with a "fork", for example, such and such work is 7-10 hours. where 7 is the optimistic scenario.

Answer 17

To estimate the timing, a period of one day to a month is required (depending on the size of requests). In this case, the estimate of the terms must be paid if it exceeds the term of 3 days.

Answer 18

Read:
Brooks. "Mythical man-month". Experience in creating an operating system.
This caused a problem 50 years ago))))
The main conclusion that I took from this book is that you need to multiply your own estimate of the terms by 2, and preferably by 3, before voicing to the customer.