What is your approach to unfamiliar software development tasks?

My approach to any new development would be... 1. Ask questions. 2. Start small. 3. Build POC. 4. Seek feedback 5. Improve and Repeat.

When tackling unfamiliar software development tasks, I follow these key steps: 1. Understanding: Carefully analyze the problem and requirements. 2. Breakdown: Divide the task into manageable components. 3. Prototyping: Experiment and iterate to find suitable solutions. 4. Collaboration: Communicate with team and stakeholders for insights. 5. Testing: Ensure quality through unit tests and reviews. 6. Documentation: Maintain clear and concise documentation. 7. Adaptability: Stay open to learning and new technologies for continuous improvement.

In software development, encountering such situations is common. My effective approach has been to refrain from starting until a full understanding of the "what" and "why" is achieved. Engage stakeholders to gather comprehensive information about the feature, and delve deeper to comprehend the purpose behind it. Understanding not only the "what" but also the "why" is crucial for a better grasp of the product. Additionally, maintain thorough documentation throughout this process. And also follow the process of MVP iteration, start with small basic functionality and build on top of it with different iterations with the feedback of stakeholders.

Asking as many questions as you can before beginning a new task is crucial. Jumping right into coding might not produce the greatest results. Knowing the business reasons and motivation can help you make proper technical decisions while implementing.

use first principles to break down unfamiliar tasks into simpler and familiar problems. identify what's already solved by look at existing tools, frameworks or consult domain experts before jumping into development. Visualize often and build incrementally.

How to plan out a large project: Ask a million questions: - Who are we building this for? - What are the technical limitations? - What is the product appetite? - What does success look like? - Do we have a product requirements doc? - Do we have an outline I should follow for writing the technical spec? - Do we have any performance SLAs we need to meet? - What are we purposely not solving during this project? You’ll want to take your product requirements doc and start building out a technical spec doc. Now that we know what we are building, how will we build it? For me it all comes back to features and user stories. I like to take each feature and start thinking through how I would build it.

I was asked to write a Windows MSI Installer using the WiX Toolset, which I was unfamiliar with. How it did work out for me: I collected many written tutorials on the internet and started tinkering with them. After some days, I told my boss that I was able to make a UI and asked him for guidance. He then handed me out a YouTube video explaining the basics of an MSI Installer using the WiX Toolset. The PoC was ready after one more week.

Assume nothing. Clearly document / groom stories as if you don't know anything. These details are not for you, it is for future you. It is like a contract / loan paper which should be honored by everyone. Make a fool proof documents, if a fresher joins the team he should be able to take on the work without too much of discussions or meeting.

First, understand that any unfamiliar task is an opportunity to learn new skills. Then, start gathering info and approach it with patience as it might take time depending on your project, technology, and knowledge on the subjects. Start by trying to understand requirements: seek help and ask questions until you have the clear picture. Identify what you need to accomplish the task in terms of technical or project knowledge and start researching. Once you have the clear picture and appropriate knowledge, start breaking things down into pieces which are easier to tackle and bring you satisfaction that the work you are doing pays off. Constantly implement tests and document what you are doing. Review what you did and learn from it.

If there are others within your company who might have tackled a similar problem, always talk to them, figure out how they solved it. Don’t re-invent the wheel. Instead, see if you can extend what they have to suit your needs

One thing I found helpful is to do a small poc and keep improving. The first couple of steps will look hard but once you get hang of it it becomes easy. Discuss your approach with someone who has worked in this before. Explain them as to which feature of the language or framework you are going to use. This way you will get actionable feedback that you can use to improve your ability to use that language/framework better.

As you're unfamiliar with a task or technology, invest time in thorough research. Initially, it will be challenging, but later this process will eventually make you familiar with the subject and contribute valuable skills to your bucket. Explore best practices, examples, and documentation for sustained long-term support and optimal performance. Understand both the benefits and limitations of the language, framework, library, or any other architecture you choose to utilize. This knowledge enhances your ability to make informed decisions and ensures effective utilization of the chosen tools.

Rapid prototyping is almost always a step in my process when confronted with a problem for which a solution is not readily known. Discovering what is possible typically starts with some internet research or AI prompting. Then I come up with a hypothesis and use rapid prototyping to validate the hypothesis. Having a working example of what you are trying to achieve in my mind is a critical prerequisite to decomposition, estimation, and implementation.

Starting out, my software engineering journey felt chaotic. I grappled with the nuances of my tools, celebrating their strengths and navigating their pitfalls. The developer community became my beacon, offering wisdom and resources. Amidst the rapid tech shifts, I realized that adaptability and continuous learning weren't just beneficial—they were essential. Through challenges, I saw growth, understanding that in this field, resilience is the key to success. Also, the mostly important part is that keep mindset of engineer, what was all the time.

This one can be tough sometimes you can be left with the tools you or the client has or you are allowed to have other tools and avenues for your success, use what tools you have at your disposal and see it it gets you where you need to be or need to build and expand on what you have.

Sometimes the best solution is the one you didn't have to write. Your first instinct should be to research what is out there that can do the job or be modified to do the job.

Know your tools. Practice your craft. Expand your knowledge. Familiarity - even on a basic level - with broad range of practices, tools, methodologies, languages, patterns, frameworks, etc. will enable you to find a better fit to your current needs faster. Strive to be the master of some and novice in many.

Any research about a technology should be complemented with a Proof of Concept that adapts the use of this technology in the specific business case

I'd like to emphasize the importance of alignment and consistency in the technology stack within an organization. Typically, companies have established a set of technologies that they use for building their products. This is not just a matter of preference; it's about ensuring compatibility, maintainability, and efficiency in the development process. Most organizations are wary of a "technology zoo," where a wide array of different libraries, frameworks, or programming languages are used without a cohesive strategy. This can lead to significant challenges in terms of integration, training, and support. If you believe that introducing a new technology is essential, it's important to come prepared with strong, well-reasoned arguments.

One of the critical skills I've developed over the years is the ability to break down complex tasks into smaller, more manageable parts. This approach, often referred to as decomposition in computer science, is not just a technical necessity but a fundamental strategy for successful project management and execution. Decomposition, also known as factoring, is the process of taking a complex problem or system and dividing it into smaller, more comprehensible components. Decomposition approach came from Math and is widely used in Chemistry, Physics and other sciences.

I agree with breaking down the feature into smaller deliverable items that allow you to get fast feedback and learn along the way. In my experience, however, there is little value in estimating each of the smaller pieces. Moreover, estimating something you haven’t done before with technologies you are unfamiliar with is an exercise in frustration and futility. Get them small enough that you feel relatively comfortable that you can hold the concept in your head as you work on it. Don’t worry about how long they’ll take. Instead, if you must forecast, record how long they actually take and use that to forecast future work.

You may look at decomposition as method for mentoring and onboarding also: if you slice the task really nice you may give some parts to your newcomers - it give them smooth start and you may collect some fresh ideas)

Anything over 2 wks in length should be broken up into milestones Break down the milestones into features or user stories Break down those user stories into tasks for frontend and backend. Input these tasks into your project management software with a clear summary and acceptance criteria. Each task should be fleshed out throughly enough that anyone could pick up the task and have enough context to complete it. Breaking a complex problem down helps you: – Focus on one thing at a time – Make sense of a complex problem – Zone in on the priority for each smaller chunk – Develop accurate estimates – Gain momentum while building – Build confidence in solving complex problems

When subdividing a larger task, think of a queue, not of a tree. Avoid creating wide spanning networks of dependent tasks. Focus on atomic, completable units of work - ideally with a working piece of software at the end of each one. When approaching the estimation effort, aim for days-weeks rather than hours or months.

Understanding and implementing customer requirements in an unfamiliar project. Breaking down these requirements into smaller, manageable parts is a key strategy. This approach not only makes the task more digestible for our developers but also ensures that each component aligns with the customer’s expectations. By breaking down customer requirements, assigning responsibilities, setting testing expectations, and ensuring a cohesive integration, we not only make the project more manageable for our team but also enhance the overall quality and success of the development process.

Streamline everything.. 1. Divide: Segment task into smaller units. 2. Estimate: Assess time/resources per subtask. 3. Milestones: Set realistic deadlines. 4. Prioritize: Order tasks by importance. 5. Adapt: Modify plans as needed.

"Divide and conquer". Once you figure out the problem to solve, size it. If it's too big and complex, break it down into smaller logical units, which can be delivered separately/ incrementally while targeting the same goal and adding value to your customers/users.

Testing doesn't just mean pressing play and seeing what breaks: it means lines of automated test cases. But writing these tests *while* you develop new code can indicate that your inputs and outputs aren't well-defined or thought out, and this can lead to code with those same problems. Thinking about the problem and writing unit tests *before* new code almost always results in more maintainable code with clean interfaces. This code will be easier to change, fix, and trust by adding new test cases. The best codebases have more lines of tests than code. (While experimenting, coding without tests is fine. But in established codebases, and especially anywhere you're fixing bugs, the tests should also come first.)

Tests are something that will be read and run frequently. Nobody wants to wait hours to have their build accepted due to slow running or flakey tests

Always create tests that challenge your business logic: - Provide unexpected input data (null, undefined, ...) - Test for the negative paths - Try to individuate edge cases (just because the application is meant to be used in a specific way, it doesn't mean your user will)

Test driven development is one of the most effective approaches. It will help you avoid scope creep. It will encourage you to start with understanding the expected final outcome. It will inform you over time about breaking changes and conceptual conflicts. When applied correctly, TDD can eliminate debugging time to zero.

Don’t forget the performance tests, load tests or whatever it is called. A process that do what it is supposed to do, but “never ends” it is practically useless

Testing isn't straightforward. Yet simple. The testing motive is to break your code. So, do it. But do it logically. When taking requirements, take into consideration the user details (like age, gender, ethnicity, educational knowledge...). Make sure functionality can be utilized by the lowest in your targeted group. > If the task is all about data and revolves around the data, go out of bounds of throw exceptions and test against CRUD (user level - frontend/backend) and performance. > If task is about the transaction and security, *break the bank* and *secure bank*

My personal approach when facing issues, after understanding the problem, is to write one or more automated test, usually unit, unless it's an integration problem. Making sure they fail showing the problem, and then addressing it to make them pass. That way, we can have some guarantee, that it won't come back again in the future...

Whenever faced with a new task with. which I am unfamiliar, I find using TDD to be a great technique. Start by writing tests for the most simple problem in the domain. Write tests which are initially designed to fail(to ensure that your tests are working), then start writing code to make your tests pass. Once the simple tests are all passing, all of the time, then move on to the next level of complexity within your task. This can help you to understand the problem which you're tackling (even if it's learning to write in a new programming language).

Refactoring should happen as you go, not as a separate phase. Refactoring is changing the implementation without changing the behavior, so you need the unit tests to validate the behavior as you refactor.

When faced with unfamiliar software development tasks, my approach to refactor and optimize solutions involves several key steps. First, I thoroughly understand the existing codebase, identifying areas for improvement in terms of performance, readability, and maintainability. Then, I prioritize tasks based on their impact and feasibility. Next, I employ proven software design principles and patterns to refactor the code, making it more modular, efficient, and scalable. Throughout this process, I leverage automated testing to ensure that my changes don't introduce regressions. Finally, I measure the performance of the optimized solution and iterate as needed to achieve the desired improvements.

corollary to refactor and optimize. Build your software to be maintained. I have long lost the source of this metric but over the life of software, you can expect about 50% of software cost to be incurred during maintenance if written to be maintained, easily 90% if not written to be maintained. Keeping it maintainable? 'good coding practices' -- small, specific purpose functions/methods that are described in a sentence or two. More tests than the code to document the behavior of all the code. A build pipeline that exercises all those tests so that it is clear what the code is supposed to do, and detected if something changed.

Prerequisite for refactoring is the unit test. Keep refactoring things, to an extent that it reads like a well written prose.

Make it work, then make it clean and organized. Here is a helpful outline I’ve followed when learning new skills and frameworks. Step 1: Read the official docs, grab a book, etc. Step 2: Try it out Step 1a: Do more reading / research Step 3: Get it working Step 4: Refactor Step 5: Summarize and document Step 6: Share what you’ve learned Refactor and optimize happens after you get the initial program working. After that you want to summarize what you learned and share it with others to further cement your learning and helps others level up alongside you.

Once the core functionalities are in place, it's time to refine. Review your code, enhancing its readability, performance, and security. Adhere to the project's coding standards and conventions. Through refactoring and optimization, you elevate the quality and impact of your work.

Refactoring is a valuable practice that can prevent your code from becoming a “Legacy code” blackbox. However, you should also be mindful of the trade-offs between performance and readability. Before you optimize your code, you should ask yourself: How much will this optimization affect the overall functionality and efficiency of the project? How much will it save in terms of cost and resources? For example, it may not be worth it to optimize a service that costs 5$ to 4$, but it may be worth it to optimize a service that costs 5k to 4k.

As mentioned in the beginning, we start with a sketch. Do some rough cuts. Then we polish and perfect. But we always must polish and perfect before the piece is complete. Before we jump to the next one. The unfinished piece is for scrap, not for touching up later. Often the first rough cut will teach you enough to make a better one from scratch - you can throw away the original one.

Code reviews help a lot here. If someone does not have code reviews as part of the process yet, it's really a must for any project that have multiple people working on it. It does not only help in making the overall solution a lot better, but also helps with learning. Engineers learn a lot when reviewing each others code.

If there are actionable items for your code, be sure this is documented and tracked somewhere (in a backlog). Include your own clear and descriptive notes that are written as if you are explaining the necessary work to someone else. Later, there will be very little effort spent on reacquaintance... not to mention someone else could end up working on it.

Seek feedback at every step of the way, it need not be a formal "Demo" just pull the "Decision Makers and Primary user of the system". You can include whole world but what matters is the decision makers. Others will add good to have nice to have but decision maker will bring what is required for the business make profits.

DevOps methodology may help on this step: if your ops part in close contact with development team - you have fast feedback loop from monitoring, performance issues and clients feedback.

After coding, actively seek feedback from peers, mentors, or clients. Present your work, explaining your choices, and genuinely listen to the insights offered. Embracing feedback not only hones your skills but also showcases your professionalism and teamwork.

I also want to stress the importance of the testing and debug phase in any project. I highly recommend involving the customer in the final steps of testing to gather valuable feedback. This approach can save us time by avoiding unnecessary rework or deploying fixtures that may not align with the customer’s expectations. Before reaching this stage, conducting a basic debug test and researching the customer’s business and software usage intentions would be a wise move. Including the customer in the final steps and debug phase aligns with an agile approach and ensures a smoother project delivery.

Adopt software development lifecycle 1.) GitOps : Code review, CICD with QA testing Adopt Agile practices. 1.) use feedback loops to ensure continuous improvement, 2.) rapid adaptation, and alignment with customer needs. 3.) Early Detection of Issues. 4.) Resolve issues early, reducing the risk of major problems later in the project

If you're unfamiliar with the task to be done it's often worthwhile building a small proof-of-concept. Doing so will allow you to familiarise yourself with both the domain and the technology. You can then use the learnings from this process to refine the requirement and technology decision you make when implementing it for real. Or to refactor your PoC into a production level system.

In my own journey I’ve often wondered if software engineers ahead of me were somehow smarter or built different. However, slowly but surely I’ve made progress over the years, realizing my dreams. Here is a helpful framework for learning: Step 1: Read the official docs, grab a book, etc. Step 2: Try it out Step 1a: Do more reading / research Step 3: Get it working Step 4: Refactor Step 5: Summarize and document Step 6: Share what you’ve learned I’ve used it throughout my career to go from a graphic designer to frontend engineering, to fullstack engineer, to tech lead, and now headed towards engineering manager. If you choose consistency it works!

According to me, the first and foremost thing you need to develop is an open learning mindset. Always realise that you don't know everything, however given some time, you have the confidence to learn and figure it out. This way you will not be daunted by things you don't know or are not prepared for. Your mind will just get into a learning and inquisitive mode to help you absord new knowledge and achieve your goals. There is immense amount of stuff available on the Internet and with chatGPT you don't even have to spent a lot of effort to look for it. When you develop a learning mindset, you will not be afraid to tackle a new challenge.

The questions asked by LinkedIn are all wrong. I'm happy to see that those who answered did an excellent job of first correcting the questions, and then answering the right ones instead. Here's an extreme example: "The sixth and final step is to seek feedback on your code and your approach from your peers, mentors, or clients." Really? You're going to save that until the end? Get feedback first, by finding out who in the world actually needs this, and *why*. Otherwise, you're going on a side quest only to find that you have perfected the wrong thing, as passed to you from some proxy product owner or salesperson as passed to them by some customer. As someone said, a problem well-stated is already half solved.

I would stress the importance of trying to get as much help as possible from the wider team especially when working on complex or critical work that needs to be completed to a high standard under tight deadlines. If you get stuck or need someone to bounce off ideas, apart from your peers, it also helps to reach out to more experienced devs, keeping in mind that experience falls into 2 categories - those who have been working as software engineers or developers for a long time, and those who may not have had as many years of experience as others but who may have worked on a particular technical or functional area for a longer time than you. Always remember, asking for help is a sign of strength and not weakness.

Agile'ish PoC is Pivotal start point, regardless of the size and the volume of the task. Once core and bones is functional then the workflow should be similar to break down steps as presented at the breakdown head list(steps) of the article. And to be fair those steps not different from standard development cycle methodology. The crucial point in generating potentially successful R&D PoC is to keep multidimension vectors in mind like scalability, robustness, modularity, portability. If 3rd party open source libraries used - rely on stable version from well supported and maintained community source. The last is vital for LTS - you don't want get stack with cracking/hacking/digging thousands lines of unknown code.

This may go with item 1, know your time frame, understand expected ongoing deliverables, and management's expectations. Someone in this chain will generally be too optimistic so plan for it as much as possible. While all of the above considerations are very desirable a hard deadline/delivery schedule will derail the best intentions.