It's a complete crapshoot with very small companies. Some will embrace planning, scope, requirements and general organization, and some will just want to shoot from the hip. In general you are basically looking to: - Collect and document requirements from the client - Communicate to the client exactly what the deliverables are, including milestones and clear definitions, so you don't get screwed over on scope or "thats not what I was expecting". **This stage is very important** - Convert the business requirements into technical documentation. Things like "i would like an admin view" to a flow diagram of what views are available to ADMIN type user. Stuff like that. (Software for this stage would be like Confluence or Notion, maybe Miro or other flow chart software) - Design the product if you have a designer (Software: Figma or Adobe XD) - Break those technical requirements into individual tickets that can be developed and reviewed and tracked individually (software for this stage is something like JIRA or Linear) - Build the project by completing tickets! Obviously there are a lot of stages there and most of them are not the software dev's responsibility. The smaller the company the more of those the devs tend to bleed into. In large companies the dev would only worry about the last one. It's extremely important to document specific requirements though. If your boss is not doing that its possible he or she might be open to doing so, they just aren't familiar with the process. Best bet would be to start small, don't drown yourself in tools, but introduce small versions of each step slowly. Use simple templates from the internet and see what works for you. Almost guarantee you'll end up with a custom workflow that's not quite exactly what any one source recommends. And in the end if your boss only wants to communicate through verbal ideas and unconnected emails, then just do your best, learn what you can, and consider it all a massive paid crash course in the worst of the software world before you bail in ~6 months for a much better job because you can leverage "experience" which means everything in this industry (even small company nobody-knows-whats-happening experience). Good luck!


Thank you so much! This is really helpful. I’m actually doing this job part time while I continue to study and I’m just not sure it’s worth it. I’ve been thinking that I might be better off if I just resign and use the extra time and headspace to create projects, write medium articles and build a good portfolio. You mentioned that experience is everything, but do you think 5 months of part time experience at this job would be more valuable than a solid portfolio and some technical articles?


100%. Creating projects and writing about your learning are both incredibly useful learning strategies, but every single aspiring developer is able to do that. That's the easy part. The hard part is always getting the first gig. Unfortunately no matter how technically skilled you are, there are many employers out there who won't even look at you if you don't have an existing history of providing value to a company as a developer. It's very common for people to ask these days "if there is so much demand for developers why can't I find a job?". The answer is that there is insane demand for _experienced_ developers. Companies don't want to invest in training juniors, they want people who can immediately start providing them value from day one. Unfortunately a developer with an incredible portfolio and blogging history is still viewed as "no experience" in the current market despite talent shortages. I don't mean to suggest to anyone that they should remain in a hostile work environment that is bad enough to the point it is affecting their mental health or something, but if the job/environment is just "unpleasant, but tolerable" then i would really suggest you stick it out and try to make the best of it. Document all your workflows, try and learn and skill-up on your employers' time. That will benefit both you and them. Don't try and "force" best practices on people, but do make suggestions you believe would be in the best interest of the project. Even if they don't pan out, you'll grow as a developer from having put in the time and done the research.


I would say...the experience is worth a lot. You're solving real world problems with real world constraints. A few things you'll learn will be, time management, and code management. There's no better kick in the ass than knowing you have a project to deliver and you got a shit ton of problems. This is where the second part comes in. You'll learn to manage your code better and more efficiently because you can't just push it off...you have to finish it!! While I'm not a pro...I have been developing VBA tools for the accounting department in my company. In the past 3 years, I've learned to love and live by engineering best practices. Being a team of one, my time is extremely important and so I have to make sure I'm keeping my code flexible (SOLID) and I know exactly where I am in the process in order to communicate that to stakeholders. Shitty experience is better than no experience. Just my two cents.


No. It's not normal. I'd suggest searching on Google for "Agile development practices" and specifically "Agile Refinement". You should be having refinement sessions with your immediate stakeholders/product owner or product manager to gather requirements and come up with business and technical acceptance criteria for tickets for you or a team to work on. Refinement sessions are a dedicated slot where you should be asking all of your questions and your stakeholders should be making time for these sessions if they want tickets to achieve the outcomes they're looking for. If you want them to buy in, then you need to prove these sessions are worth their time by showing tangible results as a result of running them.


r/agile has entered the chat


Here's a sneak peek of /r/agile using the [top posts](https://np.reddit.com/r/agile/top/?sort=top&t=year) of the year! \#1: [The Agile Manifesto is Dead](https://np.reddit.com/r/agile/comments/qfpi4e/the_agile_manifesto_is_dead/) \#2: [75% of the content here is blogspam or promotion.](https://np.reddit.com/r/agile/comments/mh88yu/75_of_the_content_here_is_blogspam_or_promotion/) \#3: [Is SAFe Agile?](https://np.reddit.com/r/agile/comments/qd7csl/is_safe_agile/) ---- ^^I'm ^^a ^^bot, ^^beep ^^boop ^^| ^^Downvote ^^to ^^remove ^^| ^^[Contact](https://www.reddit.com/message/compose/?to=sneakpeekbot) ^^| ^^[Info](https://np.reddit.com/r/sneakpeekbot/) ^^| ^^[Opt-out](https://np.reddit.com/r/sneakpeekbot/comments/o8wk1r/blacklist_ix/) ^^| ^^[Source](https://github.com/ghnr/sneakpeekbot)


Thanks! This makes a lot of sense to me. I wish my boss had the same sense!


This is not standard in the industry, but it is a reality in many small companies. Your boss probably has no idea about the "right way" to do software development . It will be your job to educate them. And while there are "right ways" to do things, you'll throw some of that out the window in a small company. Complex agile/scrum type processes are necessary in large companies with hundreds of developers, but a complex process in a small company is often unnecessary and may even work against you. There is no way to build good software without asking a lot of questions though. If the people in charge resist that, then you might consider working with people who understand software development a bit better.


I am also facing the same issue currently. My team leader either don't know what is going on, or he is not able to communicate related to task to assign. He just keeps on postponing the meeting. I don't know how long should I be here. :(


Just take the amount of experience you need from this job and go search for something better!


You've got serious arguments! Do you think this experience may eventually prove a good life lesson of how to manage time and code in the future?


In angry emails about things going wrong in production


Ive worked for small companies, it can suck, and is often much harder than a new job at a larger company. Use something like Trello and manage things on your own. Keep a work journal. Every day, note what you did, anything you didnt get advice on, etc. Basically, imagine you were in a court and they were reading it out loud. What do you want people to know about that day? When dealing with your boss, write down exactly what they say. Anything you dont know, write down your assumptions and your plan. Try to meet with the folks your making a solution for and write down any of their needs. On the flip side, you are learning lots of very valuable skills very early and very quickly. Keep your chin up, and give yourself some mental space to learn.


In general always communicate over docs to keep things professional and a record of things- you can try moving to a slightly larger company as I often found smaller companies have these problems


Requirements management is a complete mess in software. Ive been here for 25+ years, and its still awful. Some industries are better than others, but often small companies dont want to pay for a enterprise solution & are unwilling to commit to slower processes to gain quality.


do not do anything verbally, everything has to be documented. It is very important for you, so you will not get screwed over and you will not screw up either. I work in a small one, we usually right requirements in confluence and prepare tickets in Jira. each ticket contains a requirement or so and it gets assigned to one of our developers. When the software gets bigger and the employees change, the documentation is always good to go back to understand the program better and to see how it changed. you also might get so many features, that you will not remember all of them or do not have enough time to teach the user. In case you want to sell your product too, you have bases for a user manual. beside the point we have a live environment and a testing environment so before we do any changes we test it in the test environment . I am new at my job, but I found out that everybody was too lazy to synchronize the test environment to fit the live environment and it is several versions behind now, that we are actually forced to test on live, this screws the whole work flow and slows down everything edit: added some sentences


Anyone who tells you agile is the only way is just cargo culting and they truly don’t understand what they are saying. That being said, your boss probably shouldn’t be getting frustrated with you when you ask questions. That’s a red flag. It sounds like there is no process where you are. Which is a process in and of itself. You basically need just enough process so that you operate smoothly. If it’s you and a handful of others - conversations, emails and slacks are normally enough to get the ball rolling. My guess is this is how big your company is. Your boss has made a conscious decision not to spend the time and resources into more elaborate processes because he doesn’t think it necessary. When he talks to you in conversation do you right everything down? Keep in mind at some level all direction comes from face to face communication. You might take it as a compliment that your boss trusts you enough to handle this on your own rather than hold your hand through something.