How to prevent making silly errors while programming on a fast faced project and also maintain the project structure,

Question

I'm working at a startup, as a solo mobile application developer as a contractor. This has been for around 5 months now. I work part time. I have 3+ years of experience as a developer.

We have a strong user feedback loop, which also means frequent and fast changing requirements.

With so many frequent changes, I miss out on many small bugs (like null pointers or forgetting to display some text fields), which are very visible to my manager (also a developer). These are small issues but it looks very unprofessional and embarrassing for me - it is very easy to fix them, but it's embarrassing when someone points it out, and then I solve it, and it also wastes my manager's and internal testers' time.

I have tried to use checklists to keep a record of things, todo comments in code, and tacking on Jira, but still I'm missing out. This has been happening for 15 days now and I'm not able to get out of this.

My manager is kind of frustrated, and doesn't trust me anymore - he thinks I'm not serious about work, and have no attention to detail. I understand that's the right thing for him, but I'm trying my best (I am supposed to work 3 hours everyday, but consistently, I am working 4 or 5 hours) but there is no improvement.

It would be very helpful if I can get some advice. Also because of frequent changes, my code structure is messed up (I use domain driven architecture pattern, but no tests).

Answer 1

How to prevent making silly errors while programming on a fast faced project

Test.

also maintain the project structure,

Work on the structure.

We have a strong user feedback loop, which also means frequent and fast changing requirements.

This is why Sprints were invented. If you're using them then you should get at least 7 days of unchanging requirements as a target to hit.

I miss out many small bugs (like null pointers or forgetting to display some text fields), which is easily seen by my manager (also a developer), those are small issues but it looks very unprofessional and embarrassing for me, it is very easy to fix them, but embarrassing, when someone points it out and then I solve it, also wasting my managers and internal testers time.

To some extent this is the story of every developer. No one cranks out perfect code. After a certain point it's unhealthy to withhold working code from review because you want to keep polishing it. A second set of eyes will always find what you missed faster than you will. They will also let you know what's ok to ignore by ignoring it.

This has been happening for 15 days now and I'm not able to get out of this.

This is a concerning statement. If you feel trapped you're not going to perform well. Consider looking for a healthier environment to work in. Take the time to develop options. Even if you don't use them, having them makes life better.

My manager is kind of frustrated doesn't trust me anymore, he thinks I'm not serious about work, and have no attention to detail and I understand that's the right thing for him

I have no samples of your work to judge but you have 3+ years of experience. Presumably not all with the same manager. Is your manager right? Has something changed? The environment you work in can have a drastic impact on your coding. Has that happened?

It can be very hard to find the confidence that will let you judge what's impacting your work. It's all too easy to let your ego get tied up in that. Letting criticism crush you will not help. Identify causes.

What could help is getting feedback from a peer reviewer. This should be a fellow programmer at the same company (so you aren't leaking secrets) who you can repay by reviewing their code. This will improve your code before it gets to your internal tester or manager. It's an accepted industry practice. I don't see any good reason being a remote part time worker should exclude you from doing it. It depends on honest communication. It works much better when it's not your manager doing it.

I am supposed to work 3 hours everyday, but consistently, I am working 4 or 5 hours

Stop that right now. No one is impressed by the guy that works extra hours. It's more likely to hurt your reputation then help. In some situations it's outright illegal.

It would be very helpful if I can get some advice, also because of frequent changes, my code structure is messed up

The fancy term for this is Technical Debt. It will slow you down as time goes on the more you ignore it. When you start work on your next task this should be the first thing to tackle. Restructure code so that the next task is easier to do. Be conservative. Don't restructure everything. But clean up where you're working. No one will ask you to do this but if you don't, working just gets harder and harder.

I use domain driven architecture pattern, but no tests

Test!

Answer 2

Even on small projects, it's advantageous to have:

1. Code Linting (Formatting)
2. Tests
3. Code Coverage
4. Build and Deploy Automation

Instead of: Write code, commit. Have users test it out.

Linting,Tests, and Code Coverage can be automated.

Build and Deploy - Automate this, automatically run lint, tests, and coverage. Fail the build if something is wrong (test doesn't pass etc.)

In addition to these steps, having a peer or code review can also help. When creating a new feature, at the very least create a branch for it, commit, create a pull request that requires at least one review before merging. Code reviews can help find or improve code by having another set of eyes on the code.

If you do these things up front, very few defects will end up in production, and you would certainly catch the silly things like nulls as your tests should have a scenario when you pass absent or bad data through the system.

It's a little slower this way, but you have more predictable results and it will build trust with your manager.

Over time, this will be more efficient and you should be able to release code practically every day to production with high confidence that nothing will break.

Answer 3

This will not be an acceptable answer, but there are some things that can be improved.

Clean Development

Code checkers (were already mentioned) like clint, SonarLint. I use them, and certainly on encountering a new existing project. Consistent and good naming and hundred of things you probably are aware yourself. You are using architectural design: one should not overdesign, but have clear separation of aspects/concerns. If still messy at times, reconsider the simple MVC pattern in some variation.

When after some time the code becomes messy, for instance coming back for a change request or bug ticket, also do some fast maintenance, cleanup, simplification. Called technical debt. An entire redesign is only a last resort, and only if it simplifies. Detect pragmatical milestones; separate GUI from business logic, already two milestones, achievable separately with mocked data. Per extra feature a milestone.

Be able to communicate, tell what you are doing, what you did. Concisely, short. That keeps you from being a submarine developer & under pressure. Consider the requirements, plan them, and when usefull ask feedback.

Test Driven Development

Domain Driven Development is fine, and can be continued. But also do Test Driven Development:

• Separating logic from the view code.
• Having many unit tests.

This will speed up development involving processing, and guarantees code quality. It serves to capture regression errors later. If you rather start with unit tests, it is faster development. It separates GUI from business logic, which is fine.

Documentation, But Done Right

JIRA would theoretical be ideal, if the requirements would be entirely correct and complete. In your source and version control you could keep references to the ticket when changing something. However that gives a fragmented view at most.

Better would be to do your own documentation of the business logic and further on on the implementing GUI. With change tags to which your code can refer (and vice versa). A change tag might be a JIRA ticket number or your own "legacy code tag."

This helps to reason about the business logic, and explain peculiar features in code and data. Coming back on maintenance will help you doing the best change. It also will give better insights. See questionable things and limitations.

A thin documentation describing the business logic of the system, where you touched it. Concise requirements from the (change) request and your implementation. Listing the classes.

The documentation should be in version control too (like in your personal git). In a text format like .md (mark-down), but GUI mockups (screen shots?) are just as important.

Implementing Change

Do this at the side, without loud mention. It should not take much time. Only after proven useful, communicate and ask the manager for feedback on your improvement attempts. Depending on how diametral your standpoints, you might opt for a job change.

Less money perhaps are employed jobs, but they might offer job experience in a company context, which is valuable.

Answer 4

If you are missing the buttons or controls altogether, then we can't blame anyone except you. Because those are the visible elements.

If you are a user, and trying to playing a game which needs a button to shoot. But there is no button on the screen, isn't it the point of game to have it? Isn't it noticeable?

My suggestions would be

1. Maintain mock-ups. These are rough diagrams of the UI which user needs. This won't take much time either. This will be helpful for controls and text.

2. Maintain sub tasks. Divide your work into sub tasks, just a card which has UI won't be enough. Under UI, maintain sub tasks with sections of UI. This way, you will have a track of how much is completed and you won't miss the details.

Above two consume some time, but compared to the time wasted, those two may come handy.

3. If you are writing logic along with UI, I strongly suggest to write UI first and when it is approved, then write the logic. UI is the first place where so many changes will come. Even if they change later on(one of the main points of agile and sprints), the exercise will be same. First UI and then the logic. This way you will get immediate feedback.

4. Write tests. No need to explain this. If you don't have unit test cases, do a manual unit test after development. I mean thorough testing.

Answer 5

Sounds like you project is using old outdated SDLC concepts. In Agile fast paced is only as far as we can get in the current planning which should account for proper resources to get the job done.

The planning session takes into account the people available to get the job done and decide what to do via Tasks for that 2 or 3 week sprint. It only delivers most value to the product owner looking forward in 2 week increments. The bottom line is the work is either doable in the sprint or not. If it's not then this is considered an impediment of which the team (Guided by the Scrum Master and product owner) determines the correct actions.

Developer still feel pressure under this scenario; however, in all fairness, the work itself is either doable or not. If it's not then multiple team members come together to dig the car out of the ditch jointly. Any other type of process is toxic.

Answer 6

Slow and steady wins the race. This adage exists specifically to counteract the situation you find yourself in. If you rush, you make mistakes, and those mistakes end up costing you more time in the long run.

How to prevent making silly errors while programming on a fast faced project

Because of this, this is a loaded question. The solution is to stop making projects fast-paced, because it is the source of your issues.

This is a change in the development culture, and requires more than just your activity.

We have a strong user feedback loop, which also means frequent and fast changing requirements.

One does not follow from the other. Feedback about implemented features should not lead to significant changes to requirements. I'm ignoring things like a minor UI rejiggle which take a negligible amount of time.

If they do, then it should be because the client changed their mind, at which point your company needs to extend the deadline to account for the moved goalposts which your company could not account for in their initial estimate.

I have tried checklists to keep a record of things, todo comments in code, and Jira but still I'm missing out.

You shouldn't be doing this alone. There's a reason scrum masters exist, and it's to keep a level head when the developers are deep-diving into the code. It is incredibly hard to both keep the overview and dive into the code at the same time, without underperforming in either field.

A simple daily stand up with your manager to streamline your tasks for the day will do wonders. Even if your manager spend no more time on this than the 5-10 minutes of the standup itself, it means you can focus on the tasks at hand and your manager can sanity check your work plan.

Answer 7

It seems that you are churning out more features than you can produce reliably. While other answers contain valuable tips in getting better, the issue is that there is still an output limit and even after you get better (do that, it's good for you) you'll still face demands that exceed it.

The obvious solution would be to accept less new features (or changes to the existing ones). 3 hours a day is not much and if someone wants you to take on more work they should assign more developer time to it. If pressed you can accept the demand but warn that it will be rushed and with a high risk of bugs. Don't let the manager convince you that you can do it perfect in little time (Unfortunately managers often think that what is needed also has to be possible. Sometimes technicians need to disappoint them).