- 今日推荐开源项目：《自然语言处理课程 nlp_course》
- 今日推荐英文原文：《“Your app will be finished on Tuesday.” — which Tuesday?!》
今日推荐开源项目：《自然语言处理课程 nlp_course》
推荐理由：一个按周进行教学的自然语言处理课程，课程内容包含讲座和研讨会，以及课程作业和相关的文章，如果对自然语言处理感兴趣的话可以来尝试着学习一下，讲座和研讨会的内容都是以视频的形式提供的，所以可能会需要一点英语基础，在尝试之前也不要忘了根据它的要求安装所需要的库。
今日推荐英文原文：《“Your app will be finished on Tuesday.” — which Tuesday?!》作者：Tomer Dicturel
原文链接：https://medium.com/swlh/your-app-will-be-finished-on-tuesday-which-tuesday-bffaa90d20ca
推荐理由：软件开发计划失败的十个原因，避开它们吧
“Your app will be finished on Tuesday.” — which Tuesday?!
If you search online for trends in software development you’ll find an endless supply of information on booming technologies and how tech is going to impact every sector by 2020. We hear about all the amazing changes new technology will have ad nauseam, but I’m here to question the latter part of the previous sentence. “By 2020”. For those of you who don’t speak “software engineer”, that means 2040. As the only guy at Crane.ai that doesn’t write code, I’ve been plagued by this problem for the longest time. Of course, non-coders are also part of the problem; this post was originally going to be about 5 reasons why software development projects fail, but in full client fashion I changed the spec halfway through the project and so it’ll now be about 10 reasons why software development projects fail.
1. Poorly defined (or, god willing, undefined!) outcome
“Mobile app? We built a bridge, does that work?”
One of the largest problems plaguing software development projects is a poorly defined outcome. Without proper definition as to what the “end product” should be, a project is guaranteed to fail. This is so vital that it could quite possibly change the direction of the project itself (which is why it’s #1 on my list!). I highly recommend building a specification sheet to better identify what the product will look like, what it will do, and how it will do it. More on this under communication and expectations!
2. Solving the wrong problem.
“We built a new wooden bridge that looks way prettier than the old one. Cars? Oh, no, it can’t support cars. Pretty much anything heavier than a bird will break it.”
Another common issue is solving the wrong problem. This lies along the same lines as a poorly defined outcome, yet is much broader in scope. Although you can properly identify your end product and solve the other issues discussed here, if your solution does not properly address the problem then you’ve gotten nowhere with the project.
One way to solve this is to incrementally ideate. Identify your core problem, what steps could be taken to solve it, and a possible solution. Next, constantly iterate the product through with your end user — maintain a constant review process to ensure the project is properly addressing the needs of your user, and remains a solution to your core problem.
3. Not enough communication.
“We built half a bridge, they built half a tunnel.”
Coming in at #3 is the core problem plaguing virtually every project, industry, and business — communication. Communication is vital at every level of a software development project. At an internal level, your developers need to communicate effectively to ensure they build tools and pipelines that in coordination and are properly compatible. A common solution here is to draft specifications beforehand for design, APIs, and any other engineering required in your project. This is vital to saving hundreds of hours of time that could otherwise be wasted in refactoring and restructuring. At a higher level, it’s also important to properly communicate with other teams. The marketing team, for example, needs to know what is technologically feasible before selling the concept.
Failure to communicate at this level can cause project-shattering issues; the product could end up being severely detached from what was sold, promised, built and needed.
4. No plan or timeline.
“Yeah… it’ll get done around like… maybe a couple weeks? Not sure what we’re gonna do after that…”
Regardless of whether timelines and plans are adhered to, it’s important to have one. It provides your project with a sense of structure and gives you an estimate as to when and how tasks will be completed.
Of course, a good plan reaches much further. A good plan or timeline can also serve as a common border for large teams, allowing them to operate quickly and efficiently in sprints. If a feature falls through or needs more time, then the plan/timeline can be adjusted quickly, and the budget adjusted accordingly.5. Lack of accountability.
“The buck stops… over there, bye!” — Harry Truman, probably
When shit hits the fan, someone has to be ready with a mop. If a feature falls through, it should be clear who is accountable and what steps should be taken to prevent this in the future.
It sounds childish but a common occurrence in the software development industry is “pointing fingers.” The backend engineers will blame the frontend engineers will blame the sales team will blame the marketing team will blame the legal office will blame the management will blame… This process is not only time consuming and disastrous for morale, but it leaves the core question — “what went wrong?” — open and unanswered.6. Moving the goalposts too often.
*“Ok, but now the bridge needs to also act as a runway, have 10 more lanes, and how about a park in the middle of it?”
* It’s important to keep track of a project’s goals and make sure they are met in a timely fashion. While it is possible that a project needs to be expanded or the requirements have changed, making frequent modifications to the “end goal” can not only devastate morale, but make a project outright impossible. Often times, changes are unplanned and require extensive refactoring; over time, this leads to a large amount of wasted time, and eventually a failed project.
What may seem like a small change at first could end up becoming a long-term development project.7. Inadequate documentation and tracking.
“The instructions to defuse this bomb say to pull the red wire once the power cuts off, but all of the wires are red and the power was supposed to be cut 10 minutes ago!” — James Bond, at what will be the end of his career
It’s great to follow an agile methodology and move fast, but documentation is always important. Undocumented code can lead to years of technical debt and can cause tremendous issues down the road — “what does this function do?”
It’s equally important to document the product. Every step of the process from ideation to design to execution should be well-documented to ensure that the project is easily navigable for others and stays on track. Good documentation can allow for easier project tracking — in an agile system, try a kanban board or similar to keep track of tasks!8. Badly defined system requirements.
“WTF do you mean there’s only 5 loaves and 2 fish for all 5000 of us?!”
The technical requirements of a project can be hard to gauge, but it is extremely vital that you do so. What may seem like a small extra addition may turn into a turducken of an issue, involving allocating additional infrastructure and redefining the entire system to introduce support.9. Poor preparation.
“We’re still flying half a ship.”
Often times a project is exciting and easy to jump into; however, it is vital to its success for the proper preparation to take place. Specifications need to be created, designs must be drafted, a timeline should be agreed on, and resources should be allocated.
A popular method of managing this at a technical level is Test Driven Development. Before writing a single line of code towards a project, plan out the architecture and what each piece needs to accomplish. Next, write tests to assert that each piece actually does what was intended. In this manner, you have a framework ready with set goals and can quantify progress on the development of your product.10. Unrealistic expectations.
“Ok, the app looks good — but why doesn’t the color scheme automatically change to match the user’s phone case?”
It’s important to manage expectations. Often times, the client asks for a feature that is unreasonable, impractical, or flat-out impossible. A common practice is to limit the number of changes that can be made to a spec and to have an engineer present during discussions to determine if the proposed feature is technologically feasible.
Hopefully, by avoiding these 10 pitfalls, your next software development project will be an astounding success! What issues have you run into in your software projects?
Attribution
When using recursion you answer the smallest version of a problem possible, and make a clause that stops the recursive call if that smallest version is met.
This is called the base-case, or the exit condition.
What it looks like
Here are some of the basic examples of how it works.
Factorial.rb
A basic factorial function in Ruby.
So, recursion seems fun and all, but is it actually efficient?
Efficiency is going to depend on the application of the recursion, and which language or compiler being used. In most cases looping will be more memory efficient, as recursion takes up memory in the call stack.
Often, in the case of larger problems, programmers find a simple solution using recursion, even if looping is possible. It is then up to the compiler to maximize efficiency. Some compilers will actually convert a recursive function to its iterative equivalent.
Generally, from searching around, there is no particular benefit to using recursion other than simplicity of code. Source.
What is it again?
Recursion is impressive to many because it looks rather simple, and does so much. It requires breaking down problems to their smallest instance. Even so, it often doesn’t offer any distinct advantages over looping.
So, if you want to impress interviewers, or simplify your code’s readability, learn some recursion. Learn it anyway, as you’ll run into it in other developers code. But think about whether the it will actually benefit your program.
Josh (left) with volunteer mentor Ryan (right)
Code4000 is Europe’s first prison coding workshop and is currently running a pilot with 32 prisoners at HMP Humber. The training is intense for the prisoners: nine-to-five, every day.
Five years ago Yoomee started a small in-house experiment to teach young offenders to code, but back then we didn’t have the resources to apply the lessons learned. Now we are working with Code4000 who teach prisoners how to code so they can find tech jobs when they are released.
“There’s a huge demand for coders, a huge shortfall in the UK and the rest of Europe,” said Michael Taylor, CEO of Code4000. “And prisoners have plenty of time, which is one thing you really need to learn how to code! They’ve taken to it with great speed. Some of our coders don’t even have level one maths or English, but they’re building websites within the first six to eight weeks.”
This year, Yoomee has been helping to pilot work placements for prisoners who are allowed travel on day-release to the Yoomee office whilst they serve their sentence in an open prison. We’ve recently taken on Josh, a prisoner, to work as a chatbot developer at the Yoomee office at Park Hill, Sheffield.
Josh is currently serving at HMP Hatfield which is an open prison that allows him to be released on a temporary license (ROTL). This means he can spend the day working at Yoomee rather than in the prison.
How does Code4000 work in prison?
The first phase is a training phase, teaching the prisoners the basics of HTML, CSS and Javascript, before moving onto more advanced concepts like Git, TDD, MVC, databases and full stack development using Ruby on Rails.
Prisoners aren’t allowed direct access to the internet, so they start with exercises downloaded from Code.org before moving onto building simple starter games like Pong, Breakout and Asteroids.
After that, they learn the basics of web development: how to code in both HTML (which covers the layout and structure of web pages) and CSS (which covers the style and design of web pages).
Once they’re ready, the students will enter the second stage: putting their skills to work on real projects for external clients.
The third stage will involve temporary day releases for prisoners so they can go to work with clients independently. The fourth and final step will be to help them find full-time employment as developers in time for their release. And it’s these last two stage that Yoomee has been helping with.
Introducing Josh
Josh learnt Ruby on Rails whilst attending the Code4000 workshop in HMP Humber and his skills are already impressive. He’s now working on real-world projects whilst at Yoomee. Projects include a software upgrade for Off-Axis and an AI-powered chatbot for a local mental health charity Sheffield Flourish.
“Coding is about problem-solving. Being a prisoner requires ingenious thinking to make the most of limited resources. Prisoners are adept at problem-solving and bring that into the coding world.”
The time needed to support Josh has decreased significantly since he started in the Yoomee office, and he’s now much more able to support himself using online resources such as Stack Overflow.
Yoomee is also very grateful for local tech volunteers such as freelance developer Ryan Brooks. Volunteers like Ryan are essential to help to speed up the onboarding process by committing regular time each week — mentoring and providing advice and insights on career development.
Next steps
The plan is to significantly expand the programme with Code4000 in Sheffield and so Yoomee is looking for volunteers to help mentor the new coders. So, if you also believe that an understanding of code unlocks a life of opportunities and has the power to transform lives please do get in touch with us.
In the meantime, you can find out more by watching Michael’s talk at TEDx Stockholm last month (below).
I’m trying to learn something called Data Driven Documents, or D3. It’s a JavaScript library that visualizes data. But before you can make an awesome visualization comparing how many gallons of hair gel Trump used in his lifetime, or how many toenail clippings could be transformed into organic matter to power an ecohome, consider this — one must actually learn to code to get to this high-level thinking. And you know what coding involves?
A lot of tedious, small, complicated parts of a whole. I’m talking about arrays, anonymous functions, key-value pairs, markup languages, accessor functions. I could stack up this jargon from here to the moon and we would still have plenty left to get to Pluto. But the thing about coding is, it’s more like riding a bike than memorizing a textbook. Once you understand how it works, you kind of just do it. The problem lies in getting to that point.
Coding is hard, at least to me. It’s learning an entirely new language and set of logic. It has foundations in things like math, which unfortunately is difficult. And while a strong programming foundation can be applied across languages, the technologies themselves change rapidly. This JavaScript library I am learning hardly existed five years ago. And yet it’s managed to change the way people think about journalism, data, and even communication.
The pattern I am seeing is that the younger the person is, the more likely they are to have coding skills. I’ve had four teachers in my lifetime that have taught me programming in a formal classroom setting, and they’ve all been under the age of 35. It’s almost as if programming, especially web technologies, has only become ubiquitous in the past 15 years. If you knew programming before the web existed, you were probably a super nerd who coded on punch cards.
Anyhow, the upshot of this is that I don’t see many qualified older teachers who can teach these valuable skills. Tenure-track academia tends to be chock full of people who are good at teaching theory and principles. But when it comes to explaining how Fizz Buzz works or even why a div is useful, they are totally in the dark. Skills-based training often gets placed on the shoulders of adjunct faculty, many of whom do not have adequate time and resources. And that is a problem.
The job market today is the most unforgiving it has ever been. Not because the work doesn’t exist, but because it requires skills that have high barriers to entry and are very difficult to obtain. This is especially true among entry-level jobs. Unfortunately, many entry-level jobs do not place the emphasis on higher-level thinking. It is more about skills — i.e. can you actually do the work? But for some fields, higher-level strategic thinking and skills are intertwined. This is certainly true for programming.
But the problem with programming is that in terms of writing functional code, syntax is everything. You are writing instructions that are interpreted by a computer. Even in so-called higher-level languages with more room for error, one mistake can break the entire application. Naturally, it is tough to move onto the fun design thinking when you don’t even understand the basics of JavaScript.
This is where I am frustrated. I do not feel that traditional academia is well suited for skills-based education. Classes meet for short periods of time and are often varied in breath. It is hard to spend the necessary amount of time learning an incredibly difficult skill like programming if one is juggling many other classes. Also, a lot of the classes I have taken are very principle-focused and already expect you to possess the technical know-how in order to apply the theory.
I can unequivocally say that the hardest part of graduate school has been mastering the technical tools to execute design concepts. One might counter, isn’t the only way to learn a skill is to try and fail in one’s own time? This method might work for GUIs or other more user-friendly applications. But for programming is an entirely new paradigm of thinking. It needs to be taught carefully and iteratively. It is like a system of building blocks, and if one doesn’t understand the basic elements, there is no way to learn more complicated concepts.
Right now, I am teaching myself the very basics of JavaScript and D3 because I did not understand the tool I built. I was helped very heavily by my teachers, who graciously lent their expertise to polish my project. Could I have built it from scratch, on my own? Or even explain why some parts of it were coded the way they were? To be honest, no.
I don’t want to blame the teachers here. The coding instructors are mostly all adjunct, trying to pull off something very different than what academia was designed to achieve. In my coding class last semester, the teacher had 12 weeks to teach HTML, CSS, JavaScript, and D3. Unfortunately, 2 of the classes fell during breaks, so there were only 10 classes in total. How do you teach so much content in 10 classes, when classes meet once a week and there are 15 different people who not only need to learn concepts, but also require individual help? Somehow the teacher, who was fantastic, managed to squeeze everything in.
But because of the time crunch, many people (including me) did not truly understand what they were doing.
But is this problem just limited to academia? It’s clear there is a big push to get people excited about STEM. But learning the basics can be difficult and tedious. Excitement alone cannot save us.
Maybe the question is, are there enough resources to help people learn this stuff? Do we have teachers who actually know these skills? And if not, how can we better prepare teachers and incentivize them to actually want to teach?
A lot of the problem falls within the primary and secondary school systems. If programming is so difficult and yet so integral to being useful in today’s economy, it should probably start being taught in middle school. It is hard for post-secondary education to teach such a daunting skill to people who have no background, while also requiring students to receive a well-rounded education.
But to get even more extreme, what if the entire model of education was changed. What if colleges didn’t have breath requirements, but instead only expected you to get good at one thing? It turns out these things do exist, in the form of coding bootcamps and other trade schools. It is kind of ironic that people spend a lot of their lives receiving a well-rounded education, but then default to going to an extremely specialized place that teaches such a specific, technical ability. But that’s what the economy wants today, especially in an entry-level position. If someone doesn’t know how to write a sentence, why would someone hire them to be a journalist? And if they can’t code Fizz Buzz, why would they be hired to visualize data? It’s almost as if the cart is being put before the horse, and no one knows how to ride the horse. In fact, the horse didn’t even exist 30 years ago, because it was a punch card.
If you can’t tell, I think about this often and it makes me frustrated. I do not mean to throw any of my more theory-based teachers under the bus. Most truly recognize the challenges of the modern learning environment. I suppose I just want to get people talking about academia can better teach hard skills.
At the risk of sounding like a cold-hearted you-know-what, I do not want to discount the importance of liberal arts thinking and being well-rounded. I am the ultimate liberal arts cheerleader who majored in political science, loved every minute of it, and then lived with his parents for three years after school. There is nothing I love more than reading a novel. I am a writer first and foremost. In fact, I would probably only be a writer if it wasn’t for things like the Internet upending the entire economy and making it hard for people who don’t know computers to get a job.
But the this doesn’t have to be a funeral procession. These are exciting times. I’m not going to go into the whole power of technology thing. But to quote a masked hero, with great power comes great responsibility. If we don’t understand tech, it’s going to replace us (and to a degree, already has). Academia is going to be a major casualty, as skills become more degree-agnostic and knowledge is offered cheaply and conveniently online. Soon, the only advantage academia might have over the Internet is that it can hire real live humans to teach stuff. Shouldn’t these humans be equipped with the skills that their students need to survive in this crazy world? And maybe even health insurance and job security? (A person can dream..)
Academia is a frustrating, hair-wrenching, awkward as hell, and occasionally wonderful place. For all the innovations it produced, teaching must continue to be one of them. Here are some suggestions I have to make a classroom a better environment to learn coding: