Top 10 Software Development Stories This Week

Heyo Hacker, want to win the Canadian Music Week Hackathon? On May 8–9 in Toronto developers, makers and music lovers will move the music industry forward. APPLY TO HACK TODAY.

Hacker Noon has become a media partner for Canadian Music Week’s first ever Hackathon. The Hackathon will be 24 hours of intense work, debates, brainstorming, innovation, camaraderie and fun! Each team is invited to formulate solutions to problems and create new pathways to move the music industry forward. Hacker Noon contributors Adam Winfield & Philip Plotnicki will be covering the event.

HACK TODAY.

Top 10 Software Development Stories on Hacker Noon this week:

Writing quality code under time pressure? These hackathon teams prove it can be done by SIG CTO Joost Visser. Anyone can code. There are no formal entry criteria. An inquisitive mind and a laptop is all you need. But writing quality code can be hard. Each programming problem can be solved in many different ways, some clean and straightforward, many muddled and messy. To turn an initial working solution into an understandable, adaptable, testable, reusable nugget of code takes time and dedication. But most programming happens under time pressure. Pressure to ship a feature, pressure to squash a bug. Users, clients, testers, product owners, and team mates are waiting for you to close your ticket and move on.

Two Years of Functional Programming in JavaScript: Lessons Learned by Developer, Vimer, Arduiner, and Entrepreneur Victor Nakoryakov. The article is about adventures and consequences of switching to functional JS in one project.When this story started, I was already a professional programmer with 10+ years of experience. C++, then C#, then Python. I was able to program anything. My confidence in patterns and principles I have obtained extended to a point where I saw no rationale to learn something new. “I know 90% of good parts in programming,” I thought.

Change how you perceive time by Asana Engineering Manager Greg Sabo. In the late 20th century, Francesco Cirillo invented the Pomodoro Technique. “Our unique time management method gives you immediate and lasting results. Master it, and you’ll be able to accomplish anything.” Knowledge workers all around the world started putting red tomato timers on their desks. It seems like everybody has tried the Pomodoro technique, but no one keeps using it. You set a timer for 25 minutes. Then the timer rings, and you drink a La Croix. Then, you set it for 25 minutes again. The timer rings, and you drink another La Croix. Then, you check your email, and 2 hours vanish instantaneously. “Oh, I do Pomodoro sometimes,” you then say. “I set a timer. It was kind of whatever.”

The Future of Native Mobile Apps on Blockchain — What They Should Look Like, and How to Build One Today. by jasonette Creator Ethan. I think this topic of “what would the frontend in the age of decentralized protocols look like?” is not really talked about much in the community because: (1) Most people are focused on building the backend, and people don’t really want to have to worry about centralized platforms.(2) Most of those who HAVE thought about it are building centralized products. But mobile apps are inevitable if you want mainstream adoption, and we need to start thinking differently about how an app will work in the blockchain world.

What I’ve learned from full-time remote pair programming for a monthby full stack Developer Kyle Lemon. For the past month, I’ve been pair programming with a remote partner 8 hours a day, 5 days a week. This is thanks to a new company called Microverseand their Fast Track Program. This program is designed to help aspiring developers gain the skills and experience needed to succeed in remote development positions. Remote pair programming is a core aspect of the Microverse program.Before I was even accepted into the program, I was paired with another potential student (in my same time zone). We completed a simple two-day project together in order to evaluate how we worked together. Once we were both accepted, we began the program and have been working together eight hours a day, Monday to Friday. In the past month, I have learned as much or more than I did in the previous six months of studying and building on my own.

Software: The Unstoppable Monster that’s Eating Us All by TheMap Founder Robert Mundinger, Everyone uses technology, but very few actually understand it. Everyone stores passwords, transacts business over the internet, people hear about net neutrality and self driving cars. Every company has a website, file storage system and IT infrastructure. Does this mean everyone should learn to code? I don’t think so. But should everyone have the ‘structural knowledge’ of code? I do think so. As Pedro Domingos states in The Master Algorithm: How the Quest for the Ultimate Learning Machine Will Remake Our World:

Only engineers and mechanics need to know how a car’s engine works, but every driver needs to know that turning the steering wheel changes the car’s direction and stepping on the brake brings it to a stop. Few people today know what the corresponding elements of a learner even are, let alone how to use them. The psychologist Don Norman coined the term conceptual model to refer to the rough knowledge of a technology we need to have in order to use it effectively.

Structural knowledge is essentially this: you don’t need to be able to kill a lion, you just need to know that a lion can kill you. So you don’t go in the pit.

How to develop a stock market analytical tool using Shiny and R by Data Scientist Sergey Malchevskiy. I’ve been developing once an analytical tool for analyzing the Russian stock market. The purpose was building CAPM for stocks that are included in RTSI. I carried out this analytical pipeline in R: data recieving, CAPM calculation, and chart drawing. It was implemented as R script. I periodically launched this script to apply in an investment decision-making.

Working With Software Developers (9 Tips for Product Managers) by John Cutler. Some tips for Product Managers working with software developers:

1. They’re masters of coherence in arguments, information, and statements. Expect to be called out (bluntly) on something … and for them to be right.
2. Don’t assume silence means a lack of interest. Sadly, introverts get chased out of the “business world”. In the swdev team world, extroverts AND introverts thrive (cool huh?). Many ofmy dev friends choose to chew on a thought for a long time before interjecting.
3. Imagine a world where your every keystroke is (basically) measured, scrutinized, Jira-ed, and reviewed. And ****ing up means the whole app can go down (or worse). Compare that to your world, where you can often dismiss something with a hand wavy “that’s a learning!”

How the best product engineering teams maximize value by Asana Product Engineer Eric Pelz. With perfect information, an engineering design process can be pretty straightforward: you can focus on implementing functionality while minimizing engineering complexity and risk. But this gets a lot trickier when there are a lot of product uncertainties. How do you make an engineering plan when you don’t know how it will be used or extended? In these cases, you need to have a strong dialogue between product and engineering — healthy teams don’t silo each person, but have them work together as one team. Through this, you can plan to maximize user value through incremental releases, by minimizing product and engineering risk.

The Non-Secret Formula for Writing Better Code by Torii CTO Tal Bereznitskey. (Disclaimer: everything in this post is my own opinion. However, it’s 100% true and you should not question it. Let’s get started.) I love writing clean code. I want my team to write good and clean code as well. The problem is that everyone defines “clean code” differently. Here’s my non-secret formula for writing clean code that leads to less bugs, easier to change and makes me happier. What is “better code”? I enjoy working on codebases that focus on:

Readability. The code should be easy to read and understand. The why and howshould be clear in the code.

Simplicity. Code simple. It shouldn’t dependent on assumptions you can’t read in the code. Code is simple when it is difficult to use it in a wrong way. Hard to break it when adding capabilities.

Consistent. Consistent indentation. Consistent naming. Consistent file structure. It doesn’t matter what style, paradigms and decisions were taken — be consistent.

Things I couldn’t care less about: making the code generic, forcing design patterns, the known “right way” to do it and un-needed performance optimizations.

Until next time, don’t take the realities of the world for granted.

Kind Regards,

David Smooke, AMI

P.S. Want to win the Canadian Music Week Hackathon? On May 8–9 in Toronto developers, makers and music lovers will move the music industry forward. APPLY TO HACK TODAY.