Category Archives: Week-14

What is the difference between a software framework and a software architecture？

Software frameworks are reusable “semi-finished” software for domains (such as ERP, computing, etc.) that implement common parts of the domain and provide well-defined points of variability to ensure flexibility and extensibility. In other words, the software framework is the softwarenation of the results of domain analysis and the template for the final application in the domain.

With the expansion of software scale, wide application and the development of software reuse technology, the software reuse based on subroutine and class has a lot of shortcomings:

(1) The library of the subroutine is becoming more and more huge, which makes it difficult for its users to master

(2) Most classes are too small to do all the useful work by themselves

It is for these reasons that a set of classes (modules) are considered as a whole in reuse, resulting in a software framework. The software framework contains at least the following components:

(1) A series of modules to complete the calculation become components

(2) The relationship between components and the interaction mechanism

(3) A series of variable points (hot spots, or adjustment points)

(4) Behavior adjustment mechanism of variable point

Developers through the software framework behavior adjustment mechanism, peculiar to the general application domain software module bound to the variable point of a software framework, and got the final application system, this process is called software example of a software framework, the existence of software framework allows developers will be the main energy on the development system of the module, so as to improve software productivity and quality.

The behavior adjustment mechanism of the software framework refers to how to adjust the variable part of the framework for the specific application and how to add the method and rules of the specific application module at the variable point.

Ii. Software architecture

Software architecture is a sketch of a system. The objects described by software architecture are abstract components that directly constitute the system. The wires between the components describe the communication between the components explicitly and in relative detail.

Software architecture, by definition, is divided into two camps of ‘constituent’ and ‘decision-maker’, which are described as follows:

The componentized view of software architecture is that the system is described as computing components and their interactions. It has two very obvious characteristics:

Focus on the object of architectural practice — software, with the software itself as the object of description.

This paper analyzes the composition of the software, and shows that the software is not a whole in the sense of “atom”, but a whole composed of different parts connected through a specific interface, which is very important for software development.

Decision-makers believe that software architecture involves a series of decisions, mainly including:

Organization of software systems

Choose the structural elements that make up the system, the interfaces between them, and the behavior that these elements exhibit when they cooperate with each other

How do you combine these elements so that they gradually synthesize into larger subsystems?

The architectural style used to guide the organization of the system: these elements and their interfaces, collaborations, and combinations

Software architecture is concerned not only with the structure and behavior of the software itself, but also with other features: usage, functionality, performance, elasticity, reuse, understandability, economy, and technical constraints and trade-offs.

Personal understanding: When software engineering has a certain scale, software development does not exist in the form of data structure + algorithm, but “divide and conquer” software based on many factors such as technical choices and user needs. The main task of the architect is to divide the software into different modules and define the interfaces between modules.

Sources:

https://softwareengineering.stackexchange.com/questions/229415/difference-between-an-architecture-and-a-framework#:~:text=An%20architecture%20is%20the%20the,that’s%20designed%20to%20be%20extended.&text=Frameworks%20are%20specifically%20designed%20to%20be%20built%20on%20or%20extended.

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

DRY (Don’t Repeat Yourself)

https://thevaluable.dev/dry-principle-cost-benefit-example/

I’ve chosen to talk about a very simple design principle this week called “Don’t Repeat Yourself”, DRY for short. It’s a topic that is covered in this class according to the syllabus and I chose it since its similar to another topic I covered YAGNI in that they’re easy to understand design principles. The meaning is quite self-explanatory, don’t repeat code since if you need to change the behavior of a certain project, you’d have to rewrite numerous lines of code if DRY wasn’t applied. However, applying this principle to everything isn’t efficient either. Trying to apply DRY everywhere causes unnecessary coupling and complexity which also leads to more difficulty changing behavior. According to the link above, using DRY means emphasizes knowledge above all else. What it means by that is that when designing and constructing software, one should have the knowledge of when to apply DRY and when not to for the sake of the readability and efficiency of the code.

In that context, DRY reminds me of the importance of resources in a computer when running something. If you want something run faster, you’ll have to sacrifice more memory. And when you want something to have more memory, you’ll have to sacrifice more speed. Both are valid choices; it really depends on the needs of the software and the user. Say for example, I want to create a program that lists all numbers from one to 100 which I do by writing out a thousand lines of code in which each prints a number. However, if I implement DRY, then I could create an integer variable r and a loop which prints the value of that variable and increments it by one until r equals 100. But the case where I want to alter the behavior to list every odd number between one and 100 is where thing get a bit interesting. In the DRYless scenario, I can simply delete the lines of code that print even numbers. Yet in the scenario with DRY, I’d have to add a condition that skips printing variable r for that iteration of the loop. You have to sacrifice complexity for readability and vice versa. Though the choice is ultimately up to what works best in the current situation. Like in my example, the added complexity from DRY doesn’t really harm the readability, in fact it improves it in some ways, at least in my opinion.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

Design Patterns

Earlier this semester, we worked on an assignment regarding design patterns. I found this interesting as I took a deep dive into learning more about facades. As I’ve gotten deeper into the computer science program, assignments and projects have naturally gotten bigger and bigger. I was excited to learn more about facades, because it relies on two aspects important to large scale projects: simplicity, and restriction. It can make complex projects a bit easier to follow, as well as limiting what a client has access to.

While I learned a lot about facades through this assignment, I felt that I didn’t personally study enough about the other gang of four design patterns. To familiarize myself further that what I learned in class, I listened to episode 34 of the “complete developer podcast”, focused on design patterns. It wasn’t a thorough as I would have liked, but I was able to familiarize myself a bit more on behavioral and creational design patterns. Having studied facades closer, I was already a bit familiar with structural patterns. From their explanation, these 3 types of design patterns have a lot of cross over but tend to be categorized separately primarily for human understanding. I would have liked if they discussed some actual pattens within the creational, structural, and behavioral categories, such as certain ones they use more often than others.

One key takeaway I had with this podcast is how universal these object-oriented design patterns are. One of the hosts was appreciatively saying how he’s a .net developer but could talk to a Java or Ruby developer about any of these design patterns. They may not be familiar with the language, but they would be able to follow the structure of the code. The patterns themselves aren’t that complicated, but they’re capable of facilitating much more complicated programs. I also thought it was interesting, they referenced how some languages don’t need these patterns depending on the level of abstraction built into it.

I found their criticisms of design patterns to be the most useful to me. The hosts discussed certain misusages of design patterns, and these are things I can keep in mind going into the future. In particular, as some programs evolve, they may require a different design pattern than what’s originally implemented. What I take away from this is that it’s important to diagram your project before you get too invested in it. A simple UML diagram can likely show you if you’re using the right pattern, or if you’d need to change as you get further into the project.

An Introduction to Design Patterns

From the blog CS@Worcester – Derek's Design by dereksspace and used with permission of the author. All other rights reserved by the author.

Refactoring

No one likes messy code, and everyone likes simplified code, so I was interested in learning more about refactoring. While the idea of enhancing code sounds fairly intuitive, I wanted to learn more about tips and practices to use when refactoring code. In the past, I’ve been guilty of leaving my code in rough shape, until after I finished. While my habits have improved, I still have a lot to learn in these regards. To help learn some refactoring methods and practices, I listened to episode of 78 of Full Stack Radio, with guest Ben Orenstein. Orenstein, dubbed “one of the refactoring guys”, formerly worked at Thoughtbot in Boston, and now offers a course on refactoring, as well as gives lectures on the subject.

What I really liked about this podcast with Orenstein is how direct he was with all his tips. None of his advice sounded complicated, because he used very simple, explicit language. In fact, this type of language demonstrated one of his tips: “make the implicit explicit”. For example, give full words when naming object. If there’s an intermediate equation in the middle of a method, leave comments or naming conventions that clearly state why it’s there and what it leads to. Too often, I’ve used vague abbreviations in my naming conventions. While in most small-scale programs, this isn’t an issue, I realize this could be very problematic on larger projects.

“first make the change easy, then make the easy change.”

One of the best tips I thought Orenstein offered during the podcast was preparatory refactoring, or to refactor code before making changes, rather than refactoring while making changes. In this regard, your preemptive changes can cause you to have to make less changes further down the line. He gave an example of once refactoring code prior to a new feature being implemented. In the end, the new feature was pulled and not implemented, but his refactoring in advance still improved the codes functionality.

I feel like I took a lot away from this, from small tips to things I never thought about. Something that caught me slightly off-guard was when Orenstein talked about not wanting to return null values but replacing them with empty arrays. I don’t recall ever learning about this, and they didn’t go into much detail about it, so I researched it a little further on my own. This podcast helped highlight the importance of refactoring and I’m sure I’ll continue to research more refactoring methods throughout my career.

https://fullstackradio.com/78

From the blog CS@Worcester – Derek's Design by dereksspace and used with permission of the author. All other rights reserved by the author.

It’s Easy to Break Promises

Context

I’m currently writing a Node.js package for a wrapper I’m calling a curfew-promise. It’s simpler than I thought, but it is still worth doing in my opinion. The package exports a single function that returns a promise. The promise has “3” parameters with the function header being: (curfew, func, ...args). The promise then performs func asynchronously (so func itself can be sync or async). It passes ...args to that function when it’s called. Lastly, the key idea here is that if func takes longer than curfew milliseconds to complete, the wrapper will become a rejected promise.

At first, it seemed like a tough task, until I discovered the built in Promise.race() function which creates a promise which we can refer to as the racePromise. That function then also takes in multiple other promises. Whichever passed in promise resolves or rejects first, its value is then passed onto racePromise. I can achieve my curfewPromise then by creating one promise that runs func and one that rejects after curfew has passed. Whichever finishes first becomes the value of the promise the function returned. The only way I’ve found to pause an async operation in JavaScript is via await new Promise((resolve) => { setTimeout(resolve, duration); }); This line, when placed into any async function, will pause operation until duration has passed. You can also remove the redundant brackets and shrink it down to await new Promise(r => setTimeout(r, duration)); , but I prefer to be more consistent.

JavaScript is NOT Multi-Threaded

JavaScript runs in a single thread. The way it pretends to be multi-threaded is by switching back and fourth between tasks to give all of them a little bit of time until they all finish. JavaScript is also an interpreted language. This means while trying to test my package, I had a lot of trouble. I spent a few hours trying to understand what was going on and now that I have, I’m going to write about it to save you trouble.

The Code

I was completely convinced that JavaScript itself was just broken. Here is my package, at least in its current state: (If you’d like to use this or see the modern version, check the GitHub page (soon to also be on npmjs.com))

module.exports = (curfew, func, ...args) => {
    let waitId;

    async function wait() {
        await new Promise((resolve) => { waitId = setTimeout(resolve, curfew); });
        return Promise.reject(new Error("Curfew of " + curfew + "ms have elapsed."));
    }

    async function perform() {
        const value = await func(...args);
        if(waitId) clearTimeout(waitId);
        return Promise.resolve(value);
    }
    
    return Promise.race([wait(), perform()]);
}

wait() creates a promise (using async notation, since from what I’ve read that is more ideal than direct promise notation) which waits until curfew has passed, which then rejects with a useful stack trace message. You’ll notice I’m also storing waitId, which is the ID of the setTimeout call. This way, if func finishes before curfew, I can cancel the timeout and not waste performance. I’ll also be looking into ways to create cancellable promises. I’m aware there are already packages that do this, but I think I’ll benefit from doing it by hand. I could make wait() a synchronous function that simply returns a waiting promise that calls setTimeout for reject, but I chose making it like this because then it matches the form of perform() (two async functions), and it allows me to write two lines that are visibly neat rather than trying to force everything into one line.

perform() creates a promise that waits until func is finished. Once it is, it’ll attempt to stop the waiting promise. If the promise is still waiting, it’ll stop it. If the promise has already rejected, it will do nothing. Then, the function returns a resolved promise with the value from func. I chose to write return Promise.resolve(value) instead of return value, which I understand to be the same thing, for consistency once again, and I think it makes the code more readable overall.

Lastly, I am creating the promises off of these functions and making them race. The function returns a promise that resolves or rejects whenever the first of the two – wait() and perform() – finish.

The Problem

I was able to narrow down the problem to this line: 

        const value = await func(...args);

All of my tests had worked until I did something like the following:

const curfewPromise = require("./index");

// Broken Promise 1
console.log(curfewPromise(10000, async () => { 
    for(i = 0; i < 1000000; i += .001);
}));

// Broken Promise 2
console.log(curfewPromise(10000, async () => { while(true); }));

I found that for broken promise 1, despite the fact that curfewPromise returns a promise, it wouldn’t finish until the for loop finished. Even if I set the curfew to 0, it would take until the for loop completed. Broken promise 2 would never even end. I purposefully wanted to test these edge cases, where something would actually take a long time for ever (a good example for why I want the ability to cancel a promise).

The problem that I realized so frustratingly last evening is, and say it with me, JavaScript is NOT multi-threaded. Yes, when you run an asynchronous function, you can do other things in the meantime while it finishes. But as far as I can tell, JavaScript does this on a line by line basis. If you have a single line that is very slow or infinite, JavaScript will start running it, as that’s how asynchronous functions work, and then after some progress, it will move on. The thing is, you can’t make progress until that line ends. In the case of an infinite while loop, it will never end. In the case of a very slow one-line for loop, it can’t move on until the for loop is finished. Promise.race() cannot return a promise, so curfewPromise cannot return a promise. Once the for loop actually ends, it’s a gamble to decide which non-neutral-state promise will be chosen to have won the race. (Also keep in mind when using very small curfews, there is internal delay and it may not behave how you expect).

Conclusion

JavaScript is not multi-threaded. Make sure you keep that in the back of your mind. I was inadvertently testing for a case that shouldn’t ever even happen. While it was frustrating trying to figure out what was wrong, I still think that this kind of struggle is necessary in both life and learning. I always learn the most in coding when I’m trying to find out how to do something and I have 20 tabs open.

While this is a simple package that does something many developers probably can do easily, I still want to spend time making it and even upload it to npm. I think even though it’s simple, the function still helps clean up syntax to improve readability and reduce lines. I also think making it an external package helps to reduce complexity in your projects and helps me use it in multiple projects. Maybe someone can also look at it for help when learning how promises work.

At the end of the day, promises and asynchronous functions are an incredibly valuable tool in JavaScript and the illusion of multiple threads helps in most situations. Just be careful to not break your promises.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Finding the Pattern in AntiPatterns

For this week, I will be discussing about anti-patterns. I chose to talk about anti-patterns because it relates to one of the topics on our course syllabus, and it seems like it would be good for me to connect and refresh concepts learned in the previous blog posts to anti-patterns; for many of the design patterns and software concepts learned are used to prevent anti-patterns.

To supplement my knowledge on this topic, I watched two youtube videos and read one article on anti-patterns. The first video I watched was a very short video about a developer who introduces the concept, anti-patterns. In the video, he connects anti-patterns to code-smells and basically says that code-smells serve to indicate potential/likely problems in your code, which are the anti-patterns. The second video I chose was lengthier and was by the infamous ‘techlead’, where he satirically talks about his favorite anti-patterns he has seen in his work experience. Although satirical, I was able to decipher why anti-patterns are important to catch and also was able to learn some anti-patterns from his talk. The third source, the article served to list more formal definition and examples of anti-patterns. The article referred anti-patterns as “… a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences”. The article also listed examples of anti-patterns that were similar to the ones discussed in the techlead video.

I chose these three sources in that particular order because the intro video helped me better understand the general picture of anti-patterns, whereas the satirical anti-pattern video and the formal anti-pattern article helped to give more depth and understanding of anti-patterns. The satirical anti-pattern video also included real-world examples from an experienced developer which were helpful as well.

From all three sources I was able to consolidate a better understanding of anti-patterns and can see how they connect to previous material learned in my college courses. An important argument that caught me in the techleads videos was the importance of preventing/catching anti-patterns. He explains that antipatterns are dangerous because they are often irreversible and extraordinary hard to refactor once they are embedded into the architecture or code-base, and over time the damage accrues. In addition the anti-pattern article explains that anti-patterns are important to catch early because it may become a bad habit which will repeat itself. Many of the anti-patterns noted both in the anti-pattern video and article, pointed out common code-smells which appeared to be unnecessary-complexity and obscurity; which exemplifies the need for simple and readable code. This is also a common theme noted in the previous blog posts as well. One of the anti-patterns that I can relate to is the over-usage of refactoring, which is explained as bad because it slows-down readability of code during a code-review; yet it is taught extensively in some CS institutions. Overall, this topic made me realize the importance of learning proper usage of software design techniques and concepts in order to prevent anti-patterns in our code.

Sources linked below

https://www.javacodegeeks.com/2011/10/programming-antipatterns.html

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

REST API Design

Hello everyone and welcome to week 14 of the coding journey blog. In this week’s post I will be talking about REST API and it is an important topic when it comes to the web. REST API stands for representational state transfer and the main purpose of is that is is designed to take advantage of existing protocols. REST has the option to be used on practically any protocol, the main advantage it takes is over HTTP which is used for Web APIs. The main benefit for REST API design is that software developers don’t need to use any additional software or make downloads to take advantage of the protocols. It has a lot of versatility as it allows you to build an API that accustoms your vision and as well as the needs of any clients. There are six key constraints to REST API design that people need to be aware of when deciding to use the API and if it fits your needs. These constraints include client-server, stateless, cache, uniform interface, layered system and code on demand.

The constraint on client server revolves around the idea that the client and the server need to be independent of each other and need to be separate. In essence, developers should be able to make changes to their applications without impacting the data structure or the database design of the server. This goes vice-versa as the developer should also be able to make changes to the data structure or database design server without effecting the application for the client. Next constraint is that REST APIs are stateless and so calls should be independent of one another and that it contains enough data required to complete itself with no errors. It should not rely on data that is stored in the server and should do with the data it is provided in the call. Next constraint is that a REST API should be designed to allow the storage of cacheable data. Essentially, the response needs to indicate that the data can be stored up to certain time limit or in real time it should not be cached by the client.

Uniform interface is the next constraint and it should allow independent upgrades of the application without having the application’s services attached to the API layer itself. This is essential to separate client from sever. A layered system, which is another constraint, is a system composed layers as each layers serves a different purpose or function. This design principle is important in most software as different layers of architecture allows an application that is more scalable. The last constraint is code on demand which allows for code to be transmitted through the API to use within the application. It creates an evolving application that doesn’t only depend on the structure of its own code. Overall, REST APIs are important for web projects and I will certainly use them going forward.

For more information on the topic:

https://www.mulesoft.com/resources/api/what-is-rest-api-design#:~:text=REST%20or%20RESTful%20API%20design,when%20used%20for%20Web%20APIs.&text=REST%20API%20Design%20was%20defined,in%20his%202000%20doctorate%20dissertation.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Blog #4: Rest APIs

For the last month, including the our class’s most recent homework assignment, we have been working on Rest APIs. In the last assignment, we had to construct different Rest API Endpoints. For this blog, I wanted to learn a lot more about Rest APIs and try to master them better. I found a great blog about it all on stackoverflow.blog, and I will attach a link to that blog at the bottom of this post. I definitely recommend checking it out to learn more on this subject like I did. Rest APIs are among some of the most popular available web services that is used to allow clients and browser applications to communicate with a server. These APIs must be designed in a way that keep in mind account security, performance, and easy usability. An important thing for Rest APIs is JSON. Almost all networked technologies can use JSON as it is the standard for transferring data, and it is accepted by Rest APIs for request payloads. A lot of what the blog I read goes over is how to write Rest API Endpoints and coding. It explains the importance of including error handling, filtering, sorting, and nesting resources. It shows even more specifics like how collections should be named using plural nouns rather than verbs. This blog is super great for helping with every single specific when writing these endpoints, even down to the exact code to use for all the different common HTTP errors. It later goes on to explain using cache data to improve performance as well as specifics for versioning APIs. Overall, this blog taught me a lot more about writing these API Endpoints, and the best part is it helped show how it all is done with clear examples of actual code. It even came in helpful during my homework assignment earlier this week. Anyone looking to learn about or brush up on this topic should follow the link to see the blog that I used to research for Rest APIs, and I guarantee it will be extremely educational!

Best practices for REST API design

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Blog #3: UML Diagrams Cont.

In a previous blog post, I did a little research on UML and ER diagrams, and tried to express how valuable I believe they are in the real world. Today, I plan to dig deeper into the specifics of these diagrams like their formatting and meanings (if one were to look at a finished diagram. There are many specifics for a great UML Class Diagram that help to make it even more useful than simply drawing it out to represent different programs or databases. The example I discussed in my previous post when I referenced this was how the difference between a plus or minus sign before variable names shows how the variable can be public or private (plus being public and minus being private). The next thing I would like to attempt to explain is the importance of how the lines between boxes on the diagram are drawn. Each is specific enough to show exactly what type of relationship is being made between the boxes using arrows, triangles, dashes, strikethroughs, and more. If there is a full line between two boxes then it is a relationship and having a triangle at one or more of the boxes demonstrates that that box or those boxes are providing many things to the relationship. If it has a strikethrough instead, then it is providing one thing (two strikethroughs means one and only one). The boxes can have one-to-one, one-to-many, and many-to-many relationships depending on how the line between them is drawn. These rules apply more toward ER diagrams, but there are many similarities to common UML diagrams. For UML diagrams, we often use open or closed arrows or diamonds at the end of our lines that help indicate the hierarchal relationship between the boxes. Using these symbols, along with changing whether the line is dashed or solid, we can demonstrate inheritance, association, and much more. So we already can see that the format of these diagrams can show more than just the basics, but let me continue to explain even more. Before I continue though, I would like to say that visual-paradigm.com is an extremely useful website that describes all of this even better than I can. I accessed it to help me research these diagrams for two different blog posts now, and I definitely recommend giving it a look. I will leave the link to it at the bottom of this post as usual. Anyways, I want to describe the formatting of the boxes themselves next. This is for UML Class diagrams more than it is for ER diagrams, but it could be applied to both. In general, each box will represent a class in some program (or a table in a SQL database), and they are often separated into three rows. The first row is the name of the class, the second row is for the variables, and the third row is for methods (or functions, operations, etc.). Each variable and method can be public or private as I already discussed, and the methods can include the parameters in the parentheses as well as the return type at the end of the line. There is much more that can be explained, but I would like to end this post by expressing that these diagrams can be made however seems most fit for us. If we do not need to know all of the details of methods and variables, we can simply make our diagram as straight forward as we want by just putting names for the boxes. This is for looking at the diagrams conceptually rather than getting stuck in the details of each class. If we want to show a lot of the class, but not all the nitty-gritty details, we can use the specification approach, which shows details of the classes, but not all. Lastly, if we want our diagram to include all parts of the classes, we can do that as well, and it is called implementation. These are all valuable methods and designs, and it is up to the user to decide what is the best for them.

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

The apprenticeship pattern Expose Your Ignorance is like climbing a mountain taller than you may have climbed before. It seems so difficult and intimidating but once you are at the top, you realize how the hard part is over and it will now be easier moving forward. You may feel great pressure if your team has a task and they all seem to understand while you have some questions or are unfamiliar with the material. It seems as though exposing to them your ignorance will ruin their confidence in you or hurt your pride. However, exposing your ignorance does just the opposite! Your team members will see that your ability to learn is your strong suit and their confidence in you will be even greater. You will not be a master in one specific field but a master at obtaining skill and knowledge in any field you are presented with.

In my own experience, exposing your ignorance can be a great ice breaker at the beginning of a project. Just because your whole team may seem more knowledgeable than you on the material does not mean that they don’t need a refresher or are just putting on an act of confidence before they do research on their own to catch up. The most direct and fastest route to the knowledge is to ask your team member who has immediate knowledge. Perhaps the situation is vice versa and you have more knowledge than your team, asking revealing questions even if they are just for review can open the conversation for people to expose their ignorance and then learn the fastest way possible. It can be hard to swallow pride and fear judgment but if you remember that the most important thing is the project then your own pride becomes secondary. It is also better to have someone ask the questions they need than to put on an act and slow things down by learning as they go when the time could have been taken to spread knowledge amongst the whole team simultaneously. Now while you still may have to learn as you go after having exposed your ignorance, at least your team is aware and can now take proper steps to aid you until you have obtained the necessary knowledge.

From the blog cs@worcester – Zac&#039;s Blog by zloureiro and used with permission of the author. All other rights reserved by the author.