Skit (previously Vernacular.ai)

Measuring a Decentralized Organization's Transparency: A Proposed Framework to Develop a Flexible Standard Why DAOs Matter: The Inspiration and Call to Action Many are calling 2022 "The Year of the DAOs," and the industry is eagerly watching to see what this year will bring to the table: innovations in DeFi and decentralized protocols, breakthroughs in interoperability, the rise of new unicorns, and of course the drama, scandals, and rug pulls that is all too familiar in this space. Many of you are probably sick of hearing about DAOs, DeFi, and Web3; in fact, I bet your mouse is already inching closer to the next tab or link. et cetera et cetera — you’ve already read dozens of articles like this before. However, reading about it and actually being in ground zero watching the beautiful chaos go down gives you a completely different viewpoint. DAOs are the future, DAOs are cool, we’re all frens, ape into DeFi, NFTs are over-hyped, With the DAO space evolving so quickly, we are already seeing rapid changes and evolution in both how we perceive DAOs, as well as how DAOs operate. Since the early days of up until just last year, DAOs were almost universally seen as groups of extremely forward thinking engineers and mathematicians working on a service or protocol that would ultimately play a role in the proliferation of the decentralization movement — public servants in a sense. At least that’s how the industry tried to impose their views on what a ‘respectable’ DAO was. DAOs were almost instantly associated with early stage DeFi projects, open source protocols and networks, and a bunch of smart people that regularly held public Zoom meetings it was cool. The DAO really before This — perhaps unfair — preconceived notion that we have imposed on DAOs for so long has already begun its inevitable evolution and there is an odd, electric feeling in the air… that gut feeling that you know something is about to explode. DeFi was revolutionary for those who already had assets on hand to experiment with, but let's admit it: the DeFi party was both life-changing and industry propelling, but something about the party felt off... almost as if we had forgotten to invite someone important. Oh shit, we forgot to invite the people that the party was thrown for— the unbanked and the oppressed. Whereas DeFi revolutionized the way that assets could be invested and spent, DAOs are beginning to revolutionize the way that knowledge, ownership, and work is being distributed to unprecedented corners of the world. Simply put, DAOs are spreading the 'crypto gospel' around the world at an unprecedented pace, and this powerful knowledge is already changing the lives and livelihoods of countless early participants. DAOs will be the main proliferators that will bridge the gap between the unbanked and the wonderful world of DeFi. DAOs can not exist without DeFi, and DeFi doesn’t seem as exciting without the existence of DAOs that will bring the people. It ain't no fun, if the homies can't have none It ain't no fun, if the homies can't have none It ain't no fun, if the homies can't have none - Snoop Dogg This “DAO-volution” is breaking the molds of one of the longest standing forms of systematic oppression which had affected every civilization and era that came before us: jobs, work, and reward (or lack thereof). Re-defining the meaning of work, how it is conducted, and how the fruits of labor are distributed is a mind-blowingly dangerous, yet the incredibly liberating concept that could be the change of course that we as a species desperately needed. The economic playing field has a chance of trending more equal than ever before, reversing a millennia-old trend of the latter. If all this sounds absolutely crazy and extreme, then you can let out a breath of relief knowing that you are completely normal. Most people thought the same about electricity, automobiles, and the Internet — but having watched the crypto industry grow since late 2015, I have become fully convinced that once a movement has begun in this space, the train will not stop for anybody or anything. Impending doom from iron-fist regulators? Not so fast. In recent days there’s been a lot of talk about President Biden’s Executive Order on the “Responsible Development of Digital Assets,” and now Senator Elizabeth Warren’s new bill that was proposed just today, which calls on the might of the U.S. government to make it harder for Russia to avoid sanctions through cryptocurrencies. Well-intentioned on the surface, but the bill would realistically affect Americans more than Russia (not to mention, impossible to enforce), as it would require the invasion of privacy of U.S. taxpayers with more than $10K in digital assets offshore through a mandatory self-reporting to FinCEN (again, good luck enforcing this). To put it bluntly, both initiatives have a lot of bark but no bite. SEC’s Identity Crisis — Crypto’s public enemy number 1 wants to be frens? When it comes to blockchain and regulation, most people think of the SEC. For a decade the SEC was hell-bent on going after project after project, and is undoubtedly the most influential regulatory body in the United States when it comes to crypto. SEC has been uncharacteristically quiet, and it has become obvious that they have come to the realization that this worldwide movement is something they can not tame. SEC Commissioner Caroline Crenshaw released a statement titled on Nov. 9, 2021 that went largely unnoticed, and could explain why the SEC has been so (relatively) quiet lately. I’ve read many SEC briefings and statements over the years, but this one was particularly uncharacteristic and I, dare I say, agreed with of the contents. Key segments from the statement: “Statement on DeFi Risks, Regulations, and Opportunities” most Whether in the news, social media, popular entertainment, and increasingly in people’s portfolios, crypto is now part of the vernacular. But what that term actually encompasses is broad and amorphous and includes everything from tokens, to non-fungible tokens, to Dexes to Decentralized Finance or DeFI. For those readers not already familiar with DeFi, unsurprisingly, definitions also vary. In general, though, it is an effort to replicate functions of our traditional finance systems through the use of blockchain-based smart contracts that are composable, interoperable, and open source Looks like after all these years of litigation they know their crypto pretty well! ... DeFi presents a panoply of opportunities. However, it also poses important risks and challenges for regulators, investors, and the financial markets. While the potential for profits attracts attention, sometimes overwhelming attention, there is also confusion, often significant, regarding important aspects of this emerging market. It’s refreshing to see the SEC acknowledge the real, valid opportunities that DeFi brings to the world. And don’t worry, I already Googled the definition for you. a complete or impressive collection of things. panoply (noun): 1) a magnificent or impressive array; 2) ...While DeFi has produced impressive alternative methods of composing, recording, and processing transactions, it has not rewritten all of economics or human nature. Certain truths apply with as much force in DeFi as they do in traditional finance: Unless required, there will be projects that do not invest in compliance or adequate internal controls; when the potential financial rewards are great enough, some individuals will victimize others, and the likelihood of this occurring tends to increase as the likelihood of getting caught and severity of potential sanctions decrease; and absent mandatory disclosure requirements, information asymmetries will likely advantage rich investors and insiders at the expense of the smallest investors and those with the least access to information. The SEC Commissioner’s concerns are completely valid; because they are happening right now, this exact moment. Someone out there, right now, is putting money into a project or asset that has no intentions of delivering a product, service, or return on investment. As an SEC Commissioner I have a duty to help ensure that market activity, whether new or old, operates fairly, and offers all investors a level playing field. I would expect this goal to be one DeFi market participants also support. To do this, the SEC has a variety of tools at its disposal ranging from rulemaking authority, to various exemptive or no action relief, to enforcement actions. The statement also briefly touched on the DeFi Money Market (“DMM”), providing an explanation of why the project was targeted in a recent action which only resulted in a slap on the wrist. DMM raised funds in the United States with promises that did not pass the Howie Test, but more importantly DMM had allegedly misused the raised funds for personal pleasure. So DMM, according to the SEC, sold securities and scammed investors. If what the SEC alleged is true, it was simply doing its job, and the last time I checked the Securities Act of 1933 was never repealed. Whether this outdated law should apply to crypto is a completely different topic which I do not wish to go into, but I thought it was interesting that out of all the projects they could have gone after (and there’s a lot, if we’re being honest with ourselves), they explicitly went after the project that they could prove misused investor funds. In the closing paragraphs, Commissioner Crenshaw made some clear call to actions: “I recognize it is not the SEC’s role to prevent all investment losses. It is also not my goal to restrict investor access to fair and appropriate opportunities. But it is my job to demand that investors have equal access to critical information so they can make informed decisions whether to invest and at what price. I am similarly committed to ensuring markets are fair and free from manipulation. Given this, it seems that there are two specific structural problems that the DeFi community needs to address: Lack of Transparency and Pseudonymity. First, although transactions often are recorded on a public blockchain, in important ways, DeFi investing is not transparent. I am concerned that this lack of transparency contributes to a two tier market in which professional investors and insiders reap outsized returns while retail investors take more risks, get worse pricing, and are less likely to succeed over time.   …    Retail investors are already operating at a significant disadvantage to professional investors in DeFi, and this information imbalance exacerbates the problem. While I do not fully agree with the call for pseudonymity, much of the statements showed surprisingly level-headed thinking and rationale that I believe the industry can get behind. While interpretations may vary from person to person, the key points that the SEC made, whether intentionally or unintentionally was, 1) decentralized projects will not be hindered as long as no existing laws are blatantly being broken; 2) the SEC is willing to — uncharacteristically — take a passive approach and allow the industry to experiment and grow, but as soon as retail investors are being exploited, they will come down with the hammer; 3) more transparency is needed to gain the trust of both investors as well as the SEC itself, so figure it out if you want continued unhindered growth. It that the SEC has given the green-light for DeFi and decentralized organizations to continue. As previously stated, the SEC is the most influential regulatory body in the blockchain space, and if they maintain this stance, the chances of Biden’s executive order following a similar approach is, in my opinion, very high. appears If there was a time for the community to come together and begin discussions on how to improve transparency and raise trust in the decentralized space, As early adopters in web3 and the decentralized networks, we must take ownership of the responsibilities bestowed, to set open standards that will bring unity and strength in web3, self-regulate the best we can, and that we do not need regulators to come in and set their own terms. It’s in our blood as DAO workers, contributors, and leaders — just as we have shown the world that decentralized organizations can successfully operate without a central figure, we must now tackle the issue of DAO and DeFi transparency. it is now. The DAO Transparency Index & Dashboard DAO transparency dashboard that actually gives the DAO value, we must first set some boundaries and definitions. This is especially hard to do since the term "DAO" has in recent months become muddied with misconceptions and misrepresentations. At the same time, the very nature and core concept of DAOs does not permit anyone to judge or try to impose "their way" on others. The spirit of free innovation and experimentation is how the space got this far, and no one has the right to try and hinder a DAO's growth regardless of how radical or silly its ideas might seem to be. There will certainly be criminal organizations that take the form of a DAO, but web2 has shown the world the terrifying power of angry communities and their capabilities in taking entire organizations down -- and I believe that spirit will continue on to web3. The ideal outcome is to use the power of data to make it obvious without having to blatantly announce it whether or not a DAO is trustworthy, or even a DAO at all. Since data requires parameters and values, almost all DAOs will ultimately "generally defined" under the same or similar frameworks which will be used to 1) Assign a transparency index score; 2) Show areas in which the DAO could improve on; 3) Shine light on areas that the DAO is excelling at. It is proposed that transparency consists of three interrelated principles: Metric A: (i.e., financial health, token liquidity, revenue streams and debts, etc.) Finance Metric B: (i.e., degree of decentralization, token holder participation, consolidation of power, smart contract execution, etc.) Governance Metric C: (i.e., financial disclosures, internal communications, social and press/media presence, etc.). Communication Independently, all three principles of transparency are necessary but not sufficient for information to be considered transparent. Further, all three principles have major components that can be tracked on-chain and off-chain. The three proposed principles are also measured in overlapped sections that give an even clearer, segmented view of the inner workings of a DAO. A depiction of the proposed principles of transparency is offered in the following figure. The DAO Transparency Index is a WIP and we invite the community to input ideas and thoughts.

The DAO Transparency Index: Measuring an Organization's Transparency & Trust

“Proof-of-Nuclear-Bombs”: a most reliable design for stablecoin utility (Part I)

I first encountered the methodology, as an way to build products, approximately 7 years ago. I had just started a new job in Paris at a new fangled startup as the mobile tech lead. I was going to be working on an iOS app. Up until that point in my career I had been exposed to several project management paradigms loosely based around or the , so to begin working with the iterative nature and the flexibility of Scrum was new and refreshing. I haven’t looked back ever since. Scrum agile Waterfall Critical Path Method This post aims to describe the steps required to be taken by teams wishing to adopt Scrum. Many books have been written on the topic. Two of my favourites are and . There are also many online sources, such as , that explore Scrum in depth; analysing each step and providing a plethora of use cases that might suit your team, product or organisation. Scrum and XP from the Trenches Scrum — A Pocket Guide Scrum Guides My experience so far has led me to believe that Scrum can be applied to almost any situation and at almost any point of a product’s lifecycle. Certainly though, there is some vernacular to become familiar with. However, all that is required is just one person with previous experience, or a person with the willingness to learn. You can begin with applying the fundamental steps and roles to a new project or a project that has already begun. You will continue learning along the way. The Scrum Workflow Scrum roles The Product Owner This person is responsible for the product as a whole. Their key responsibility is to convey their vision to the rest of the Scrum team in order for them to execute on it and build something tangible. They must typically have an in depth understanding of the product, its users, the competition and industry trends. Their background could be anything, but experience in product management is certainly advantageous. Practically, product owners perform their role by creating tasks and stories in the product backlog and prioritising them prior to the sprint planning meeting. The Scrum Master This role holds a special place in my heart. Maybe because I have played that role on several occasions. This person is responsible for assisting their fellow team members to achieve their goals. By definition the Scrum teams are self-managing and the Scrum master works in concert with that. In addition to providing furtherance for the team in order for them to realise their objectives, they are also responsible for removing blocking issues while working with the product owner. They communicate with customers, users, stakeholders and collaborators in general. They also shield the team from distractions such as new tasks that were not in the sprint backlog from being injected in there. As a side note, I’ve seen teams, typically very small ones, run their product without a Scrum master. Whatever reason you might have, someone will have to pick up these responsibilities and therefore will probably be sidetracked from their primary tasks; but if you try it and it works out, good for you! The Team A Scrum team is a collection of individuals working together to deliver the requested and committed to, product increments. They are small, between 5 to 7 people. They are also responsible for translating product backlog items into sprint tasks; breaking them down into smaller tasks where appropriate. They have to assign estimates to each task and implement them. In other words they maintain the sprint backlog. User Stories & Tasks Stories contain multiple types of work, while tasks are restricted to a single type of work. Consider breaking up user stories into tasks. User stories can be found in the product backlog as they have been created by the product owner. These are usually phrased in a way that can be meaningful to end users. They can be phrased like so for instance: As a user I want to in order to < <some action or achievement> some reason> When they are written this way you may quickly discover that a user story can be broken down into many tasks by the Scrum team. For instance a user story might require a designer and front end coder. Maybe there is some networking on the front end that requires some infrastructure work on the backend. These tasks can be defined by the Scrum team and added into the sprint backlog. A collection of user stories can be grouped up as an epic story. Individual tasks, such as an IDE upgrade for instance, don’t have to be part of a checklist of which a user story is composed of. Your Product backlog The product backlog is a collection of user stories and tasks. It’s a prioritised list, with the priority of each item determined by the product owner. The most important or urgent items are placed at the top. What I fancy about Scrum is its iterative nature. A product backlog is not an exhaustive list of all requirements. Instead it can can be a list of the desired product features you have in mind; that could be revisited, interlarded and embellished. Items in the product backlog can be expressed as user stories or tasks. Tasks, Stories & Epics Sprint Planning, Estimation & Story Points Once your product backlog has been refined with all prioritised user stories, the Scrum team can begin the sprint planning process wherein they will transform the product backlog user stories into sprint planning tasks. Here, you make estimates as a team rather than as an individual. Sprint Duration At the beginning of the sprint planning meeting you must be sure that all team members and the product owner are present. Include, where applicable, testers, designers, product managers and developers. Once everyone has gathered, a team decision must be made for what the duration of the sprint will be. That could be between 1 week to 1 month. You can choose to skip this decision making process altogether since you might have previously decided to have a standard sprint length duration of 3 weeks for example. I cannot recommend this highly enough since in my experience standard sprint lengths give your team a great flow and over time help individual team members give precise and accurate estimates on product backlog items. My favourite length is 2 or 3 weeks for a web product or mobile app and I’m quite fond of 4 weeks also. Anything above or below that seems like a lifetime or to be impractical respectively. If you’re getting started with Scrum or a new product you might want to experiment with a couple of durations and see what works better for you and your team. Product Backlog Go through each user story or task in the product backlog along with the product owner. For each item they will provide details and clarifications. They should mention what they perceive to be pitfalls that might need more nuanced descriptions. The team might try to poke some holes in the logic or flow of certain items that will be promptly plugged during this part of the meeting. The designers will add their own perspectives too. The product managers will go into detail and communicate their own expectations. Repeating the above process for all items will assist everyone to gain an understanding of what is expected of the current Sprint and make Task creation and estimation more streamlined. If you miss out on something it’s all good. Team members will be available. Questions from everyone towards everyone related to a particular Story must be encouraged to be posed as much as possible. Creating tasks At this point you are ready to create tasks for your sprint. You can go through each user story or requirement in your product backlog. For each of these you can break them up into smaller tasks in whatever way you are comfortable with. You can break them up into traditional software development lifecycle items such as documentation, unit testing, design and development, and for each of those you can break them up further. Story Points You have started creating tasks and it is time to estimate what the required effort for completing each Task is. This is not a unit of time. One story point represents an amount of effort only. A common, and personal favourite, of story point values is the Fibonacci Sequence which is 1, 2, 3, 5, 8, 13, 21, 34 and so on. You could choose 21 to be the maximum value and try to break up bigger tasks into smaller ones. That’s dependant on the product you are working on but for a web product you will certainly almost always be able to do that. Burn down chart: Remaing Work vs.Time Since a story point doesn’t represent a time value it will mean a different thing for each Scrum team member. During the estimating portion of the sprint planning session the Scrum team could identify a base task that will hold the same story point value for everyone; or approximately enough. Then, each team member can go through the task list and assign points to their own tasks. Newcomers to Scrum will discover that after a number of sprints they will be able to gain a nice sense of their velocity. The Sprint & Velocity The Sprint is synonymous to an iteration. It is a unit of time that encompasses the beginning of the total tasks and user stories implementation, and ending when a product increment has been achieved. Product increments can be defined as a release which is a version of a product that can be be delivered to a customer, a set of users or to another team. A sprint is a time-boxed endeavour meaning it’s constrained to a defined duration. These durations could range from a week to a month or two. From my own point of view it seems that 2 to 3 weeks is a popular choice. Sprints are of fixed length for the product lifecycle even though it’s not unheard of to have variable iteration lengths for each successive sprint. I would caution against having a dynamic sprint length so that over time your team velocity can be measured consistently. Velocity is the average number of story points completed by a team across iterations. It is useful in assisting us to understand our teams limits and our delivery capacity each sprint. Work that can be completed in a sprint If you are working with multiple teams, please avoid comparing team velocity. Velocity is not a measure of comparing teams but rather one of helping them improve their timing and product increment delivery capacity individually. I’ve noticed that the few times I’ve introduced Scrum to an organisation while trying to convince them to adopt it as their methodology of choice, people’s eyes always light up at the sounding of the word It’s such a positive choice of a word for what it represents: A flexible, velocity driven approach to delivering a product increment. As a synecdoche it is what inspired me at my earliest introduction to it. sprint. Done? If you’ve decided to implement Scrum with your team, you are committing that at the end of a sprint you will have a shippable product or product increment for your users or customers. This means that the tasks and stories in your sprint backlog have been designed, developed, tested and quality assured. If these criteria have been met, the feature is . done Once each user story, by way of the tasks that it’s consisted of, and each individual task that is in your sprint backlog has met these acceptance criteria the product owner can review them in order to evaluate that they meet their standards. Once they have accepted each story or task it is . done What each team defines as can, or even better must, be decided beforehand but at the end of the day it’s if it can be shipped to a customer. done done Get up! Stand up! Otherwise known as the daily Scrum meeting, or “scrum”. I prefer using the phrase “stand up”. These meetings are typically held every single day at the same time, ideally at the start of the work day, and all team members are expected to attend. This meeting can be held at the same location or remotely via skype or a hangout. The purpose of this meeting is to frame the team’s endeavours for that day for everyone’s benefit. During the meeting each person speaks in turn and mentions the following What they worked on yesterday What they will work on today Are there any “blocking issues” A civil, quick and efficient standup builds a tight and concrete relationship among team members over time. It is easy to consider this meeting as a status update on current progress which in a sense it is. A deeper approach is to see it as what each Scrum team member has committed to another team member, or to the sprint progress. By having each team member mention what they had been up to the previous day and current day, a clear picture is painted for the team’s benefit on what work has been done and what remains to be accomplished. The scrum master is responsible for removing blocking issues either on their own or by assigning a scrum team member to do so. Practically, each team member takes their turn on addressing the above bullet points. It could take approximately 15 minutes for a 5–7 person team but it could take a bit longer if there is some off topic small talk beforehand. A practice of several teams I’ve been involved with is to have calendar events for this meeting already setup until the far future. Sprint review Towards the end of each sprint a review meeting is held with everyone present if possible. That would include at least the product owner and the Scrum team. Each team member takes their turn in going through each task that was assigned to them for the current sprint. This is an informal meeting and progress and accomplishment is communicated either by description or a product demo. Others that can be present at the review meeting could be users and customers. This review is how the sprint is assessed in terms of its success. Ideally all items in the sprint backlog are . Each item that isn’t done, gets bumped back into the product backlog to be completed next sprint. A successful sprint delivers a product increment. done Sprint retrospective The Scrum master will organise this meeting at the very end of the sprint. The usual suspects could attend. People can discuss what went right but most importantly what went wrong and what measures could be taken so the same issue doesn’t pop up in the next iteration. The team should be able to answer the following questions: What went right during the iteration What went wrong during the iteration What could be done differently in order to improve? What usually comes out of this meeting is a list of recommendations, ideas, and new processes that will help the team improve. It’s rewarding for a team to be able to self-identify issues it might be having and promptly improving their own processes in order to remove them. Getting started You can check out this template board from . Every pillar of Scrum discussed above has been represented as a column on the trello board which represents your product. trello In conclusion If you decide to adopt the Scrum methodology, over time you will start seeing the results in your product and, most importantly, your team. Your sprints will make your project iterate faster and improve. Your users will be able to regularly provide feedback, comments and remarks that you will hopefully be able to loop back into your product quickly. Your team members will gain confidence in their ability to self manage, identify their issues quickly and become more productive. And of course your customers will love the predictability and frequency of your releases. Thank you. And thanks to @BashaChris for this posts beautifully crafted hand drawn diagrams.

A Practical Scrum Overview

The German Air-fleet

When the Lion Fed

This is a highly opinionated, pseudo-motivational, unconventional and almost rant-like developer roadmap article. This article is more than a compilation of best books/videos/courses to learn Python and covers the bigger issues that a beginner/early-intermediate faces on their journey. These are the undocumented problems Stack Overflow does not solve. Why Python ? Why should you learn Python anyway? Why not one of the 20 other languages trending right now? As you’re beginning your journey, this questions crops up multiple times (a day). Picking your first programming language is a lot like picking a starter pokemon. The inherent capabilities of a language are less significant than the skill of the programmer in using said language and their grit to make it into the big league. If you want to start with a different language, do yourself a favor and stop reading this article. You’ll have a higher chance of success if you stay confident in your decision and focus on your next lesson. It doesn’t matter what language you pick. But once you make a decision, you need to stick with it. There’s an overwhelming amount of noise on the internet about language/framework comparisons. Enough to give any sane individual a serious shock of analysis-paralysis or to make them doubt their decisions and abandon ship. I’ve seen early intermediates claiming to know 3–4 languages. They tend to know all the trivia about 4 but can program in none. A result of wanting to try out everything without the commitment to stick with one. Python is a seriously well-designed language. Also, there’s plenty of documentation and tutorials available online. And, it’s used in a lot of fields so no matter what your level is, there’s plenty of things to explore. But the same is true for most of the other 20 languages. Every language has it’s pros and cons along with the use cases it’s best suited for. The 3 most popular uses of Python are data crunching, writing web application back ends and automation scripts. Python is arguably the best language for beginners due to the underlying principles of the design of the language that focus on clarity and simplicity. There will always be voices telling you that you’ve made the wrong choice. 9 out of 10 times, those voices belong to people who are trying to sell you something or are troubled with serious insecurities. How Python ? Now that you’ve made your choice, let’s talk about learning Python. It’s simple. Pick a tutorial and complete it. Then, pick another. Rest and Repeat. You need continual exposure to code, along with progressive overload. Patience, persistence, commitment are required ! A single book or video course will not cut it. (and a bunch of other cool qualities) I’ve come up with a basic flow of what I’d advise a beginner to do. If you’re human your version of the roadmap will vary. Just use this for reference. (last time I checked, AI wasn’t interested in learning python, yet) It’s important to know when to move to the next level. Most people do it too late. You might prefer to pick a course on edX instead of reading a book. The overall process is more important than the individual tutorials/courses you pick. Build a strong foundation by reading books. Follow the tutorials that teach you to accomplish a single task with Python, like sending email or writing files. This will introduce you to the useful packages and libraries available to a Python developer. Inculcate a habit of reading documentation. Build small apps by using the libraries available. Gain a deeper understanding of the language and it’s tools. Learn what the experts in the field are working on. Go straight to the source. Here’s a list of useful Python resources if you’ve exhausted the ones in the diagram. . Best Python Resources at Full Stack Python While following any tutorial, make sure you code along the way. Merely, reading the code examples isn’t enough. Learn General Purpose Problem Solving There’s a subtle difference between learning a language (or framework/library) and learning to program. It’s like comparing water colors to painting. Before you , just know that it will . It will to tackle a simple problem (yes, the web apps built in most of these courses are indeed simple problems). Knowing the procedure is good, but being able to devise your own procedures is brilliant. Pay attention to programming constructs, design patterns and algorithms. These are not specific to Python and remain the same for almost all languages. pay for a ‘Full Stack Web Developer’ course not make you a good programmer only teach you a particular procedure Do it long enough and the pattern will emerge. Finding Answers If you get stuck (you will, several times), try to solve the problem before you start running in the other direction. There is a very high probability that someone, somewhere has faced the same problem before and the internet has documented proof of it. Search for the solution on the web. Also, the Python community (subset of the world’s population that use Python and actively participate in connecting with other Python programmers) is very welcoming. You can always ask people for help. Join the . Python channel on Gitter Wow Python ! There’s a lot to learn in Python. It’s used in a whole bunch of fields. Do not skip the basics and jump to specialize in a particular field. Having in-depth knowledge of Python pays off in the long run. It will result in less time spent debugging your programs while you’re working with your super special library. Learning PyTorch should come after packaging, Django after Virtual Environments. How Long Does It Take ? 9 lifetimes. It takes time to learn something well. Way longer than most people tell you. You cannot become an expert programmer in a couple of months. I would recommend that you focus primarily on Python for at least an year. There will be distractions and diversions, avoid those. But don’t be scared of branching out to learn new things. Python is not the only thing you need to become a well rounded developer. Learning Git, Markdown, HTML pays off immensely. You might also need to pick up JS or statistics along the way. Good things take time and effort. Be a learner forever, but not JUST a learner ! Understand the Learn/Build cycle There are two phases in any creative/scientific endeavor that keep repeating. The phase, where you should focus on amassing knowledge. Read books, complete every tutorial and explore what’s already been done. Learn The phase, where you create something by applying the knowledge gained in the previous phase. Stop doubting your skills, tune out the noise that says you can’t and write your own app. Only when you’re done, go back and learn again. Build Balance the two phases. Have a month or two month long phase followed by a month long phase. Most Learn Build people are too scared to start the Build phase. Become a student of the game. Explore everything about your language, learn about the pioneers in your field, ask questions, learn why something is designed the the way it is. There will be a time when you would be following on GitHub, listening to on your commutes and complying with in vernacular writing. And, you’d do it not because you need to learn, but because you want to know. Kenneth Reitz Talk Python pep8 Thanks for reading, drop a few claps if you enjoyed. Check out some other posts I’ve written, follow and reach out to me on Twitter. Ramit Mittal.

SKIT (PREVIOUSLY VERNACULAR.AI)

skit.ai

-- employees

Since n.d.

COMPANY RANKING

SKIT (PREVIOUSLY VERNACULAR.AI)

EVERGREEN INDEX #9998

Representing this company? Click here to claim and customize this page!

Skit (previously Vernacular.ai) WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

SKIT (PREVIOUSLY VERNACULAR.AI)

skit.ai

-- employees

Since n.d.

COMPANY RANKING

SKIT (PREVIOUSLY VERNACULAR.AI)

EVERGREEN INDEX #9998

RELATED COMPANIESRANK

STORIES ABOUT SKIT (PREVIOUSLY VERNACULAR.AI)

Representing this company? Click here to claim and customize this page!

Skit (previously Vernacular.ai) WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!