It’s time to write a new blog post about my experience in the HEC Paris Master of Science program. I’ve taken two new courses: Business strategy and Strategic Management of Innovation. They were somewhat related which was good for building a broad knowledge, because several concepts and topics were used and discussed from different angles in both courses. When I was a schoolboy, I liked strategy games like chess, Civilization and Command & Conquer. I had to balance building roads and factories with investment in defense and military troops. As with these games, in business it’s all about the strategy.

Let me first tell me about the Business Strategy course.

Business Strategy

The Business Strategy course was a great overview of how management consultancy works that is identify competitive advantage and pick the right strategy for the company. The strategy is all the choices that the company and its employees must make. Often times there is no right or wrong answer in a vacuum (without considering the industry and competitors) for things like pricing, choosing the target audience, accounting for learning curve, growing organically or going big fast. The external forces in the industry must be considered. For some companies offering a low price product can provide competitive advantage via economy of scale (Walmart). While for other companies, offering the high-priced product can provide competitive via differentiation (Whole Foods).

We covered several frameworks like SWOT, 5 Force model, BCG model, VRIST. The key take away is the industries are not equally profitable. In other words, some industries are a highly profitable such as soda and pharmaceuticals while others are less profitable such as an airline industry. You might think of this courses more for bigger established companies for conglomerates, but you can apply a lot of the thinking to a start up to choose better more competitive strategy (like Southwest did).

The professor had the management consultancy background. The course was straight to the point without wasting anytime on unnecessary information. The live session was had interesting real life case study. Throughout the course, I was remembering two books about management consulting that I’ve read. First is The Firm: The Story of McKinsey and Its Secret Influence on American Business which gives a good history of the biggest and most respectable consultancy firm the main service of which is the business strategy. The second book is The Management Myth: Debunking Modern Business Philosophy in which the author debunks some of the management theories including Taylorism and In Search of Excellence. You would never think about the management consultancy in the same way after reading this book.

Strategic Management of Innovation

The Strategic Management of Innovation course is about how to innovate strategically. We covered topics such as buying patents from universities, incentives, Technology S-curve, competence destroying innovation, segment zero competition, dominant design, standardization, platforms, opened versus closed, networks, and the dangers of going first to the market. The main takeaway of this course is that certain things that the mainstream perceives as undeniably good that is being the first mover and growing big fast would not guarantee the success just by themselves.

There were a few tips applicable to startups such as picking the right location for your new venture. Also, the course is applicable to executives and consultants too big or more established companies.

And as far as choosing the location for the startup, it’s better not to located in a hub of companies in your similar niche, so called agglomerate areas. Are your chances to start a tech company in San Francisco and Silicon Valley lower than in Milwaukee, WI or Dallas, TX? Maybe yes considering that R&D costs would be lower, employee loyalty would be higher and you would not be biased or demotivated by the bubble think of The Silicon Valley. In the book The San Francisco Fallacy: The Ten Fallacies That Make Founders Fail author and serial entrepreneur shares that he would have never started his company RightSignature if he were in San Francisco and knew about the major established competitor DocuSign. Instead, the author just built tool in Europe, made it a successful company and sold it a few years later.

Both of these courses were supplemented with two live sessions with the professors.

Live Sessions

The live sessions are optional and there are recordings to watch later. However, I attended all four sessions and greatly enjoyed the interactive communication with 30–40 of my classmates and the professors who gave us additional insights, answers and materials not covered in the self-paced prerecorded videos. The students joined from the USA, Europe, Africa and Asia.

The live sessions along with the Slack community, forum discussions, and peer-reviewed assignments give the feeling that you are really connected to the classmates because you see their work, challenges, and learn from years of their experience in various industries, companies and countries. It will be close to impossible achieve the same level of productivity, effectiveness and convenience with the traditional physical approach to the study.

I’m looking forward to the next courses, projects and assignments!

Originally published at http://azat.co/blog/hec-paris-3/.

My management philosophy revolves around three things but one of them is the most important because if we get it right, then all other parts will fall into place. One thing that I care about the most, and which is my main job, is people. I coach, mentor and help people to grow in their careers. I find their strengths and talents. Most people are not that great at self awareness and self observation because their insecurities, desires or emotions interfere with the clear perception of reality. Observing people from outside as a manager or peer gives much better results — a much cleaner and fuller picture.

My job is to match what people are good at (their talent, not necessarily their current skills) with the opportunities and needs of my team, or other teams within my company. If it’s a small company and we don’t have a good match, then I can encourage the person to look outside. In the end, it’s better for the company to have someone who is great at something and for that person to find a new place where he/she really shines. It’s a typical win-win but a counterintuitive at first.

With companies trying to outcompete each other in hiring in this notoriously low-unemployment job market some manager coerce, deceive and force engineers to stay at a place they don’t excited about. This is terrible for engineers and not great for companies either because they get low motivated people. I’m the opposite. For me people are first. They have different strengths and different motives. Someone is motivated by prestige of a higher title and other by respect of their peers, or money. Some people are good at backend while others like the more customer-facing frontend. Understanding them and aligning with the team and the company is the key to success.

The second part of my job as a good manager is delivering products. I’m helping product managers or stepping into their roles to fill in the gaps as needed. I’m defining the product, breaking it down into technical tasks, helping my team leads to create actionable tasks and keeping everyone accountable. I’m a fan of Google Sprint-like brainstorming and Objects and Key Results (OKRs). I let my engineers set roughly half of the quarterly goals, especially goals around technical stack, tech debt and infrastructure, because they are closer to the problems. They are the subject-matter experts. They know what’s better and more effective. My job is to balance the scale and make judgements: more technical work vs. more product work. Sometimes my job is to push for faster and more product deliveries and new features, and take on some tech debt (like when we pushed for the new DocuSign web app release to be ready in time for the conference). Other times, I push back on the product work and have talks with product managers to explain to them that we are better off to spend time on updating our tech stack and paying tech debt.

As a manager, I need to take extreme ownership even if parts of my team’s work is outside of my control. Often times, I work with different teams and even different organizations without our company. Sometimes I work with outside vendors or clients. That’s even harder. But in the end, I plan accordingly, organize, coordinate and communicate to resolve any dependencies for my projects to eliminate wasted time and to let my engineers focus on their main work (On some teams, a Program Manager can help with this work). In the end, companies must deliver what customers want and need. If we don’t deliver, then we’ll be outcompeted and there would be no need for managers or software engineers.

The last part of my work is something that I truly believe makes the world a better place that I’m really passionate and care about. My third job is meta, that is to instill great engineering culture, help out the community (within the company or outside) and improve the engineering itself. I speak at conferences. In the last few years, I spoke at over 20 conferences all over the world and taught over 1000 engineers in person. I taught probably 40,000 engineers virtually through my edX, Coursera, YouTube, podcast, Node University, Webapplog blog, Medium, GitHub and book materials. (It’s hard to quantify the actual number due to overlap of the consumers of these mediums.) My books Practical Node.js and React Quickly sold in 10s of thousands. Who knows how many, many more of these books were downloaded from pirate sites or shared for free?

Helping the community does not only feel right and good, it also boosts one’s career. I highly recommend it to anyone. I encourage my engineers (who have talents for that) to write blog posts, speak at meetups and conferences, and contribute to open source. I know a graduate form Hack Reactor, which is now part of Galvanize (I used to give lectures there). This person quit his job at a promising late stage startup that is a famous marketplace for discounted online courses. The reason was that his employer prohibited him to work on open source. What a mistake on the part of this employer. They not only lost this engineer who ended up being a very good tech teacher and an expert, but they also lost the good exposure which could have helped this company with recruiting.

If we all consider our job as a trade akin to a guild of programmer and take pride in our work and trade, then we will be enjoying the work much more. Open source is growing and becoming more and more popular. Now, software engineers can learn React or Spring and find a job at a lot of companies because fewer and fewer companies have a need or desire to build in-house tech.

This sums up the main aspects of my management philosophy. I’m a software engineering manager but this post can apply to any knowledge/informational management: people, deliveries and community. If you read this blog and your management doesn’t care about all of these three things, then maybe it’s time to start thinking if that’s a good place for you and dust off your resume and start looking for a better place to spend 1/3 of your life.

New Year resolutions don’t work. They don’t work because people make them and then forget, never look at them. It’s not your fault that your NY resolutions didn’t happen. You just didn’t know what to do. I was like that too before I discovered what works.

Write down your yearly goals and look at them every day or at least every week! It works for me without failure. I lost weight, wrote 18 books, learned a new language (and a few new programming languages), spoke at tons of conferences and traveled to 36 countries.

If one of your goals for 2019 is to engage your mind, grow in your career and develop intellect, then learn and master Node.js and full stack JavaScript. Make it your weekly practice to take courses on Node University, watch conference talks on YouTube and read blog posts. Schedule that freaking time in your calendar and never cancel the appointment. (I prefer Fridays cause they are slower.)

Here are some of my resources (free and paid) for you for 2019:

• [NEW] Practical Node.js 2nd Edition in color print: https://amzn.to/2BK3boh(recommended)
• 30 video courses at Node University https://node.university/p/premium-membership
• Practical Node.js 2nd Edition on GitHub (unedited): https://github.com/azat-co/practicalnode
• Node University Podcast https://nodeuniversity.simplecast.fm/
• 200+ blog posts: https://webapplog.com

#nodejs #newyear #javascript

Does someone have to be a genius to be a programmer? It definitely helps but only if the person is NOT afraid of hard work. You see, a lot of smart people are compelled by challenging and tough problems. They want to solve complex issues.

Programming can be creative but at the same time there are periods of time when programming can be boring and tedious. A good programmer will be smart to automate a boring task but he won’t hide from a boring task if automation is impractical. When I taught at the Hack Reactor dev bootcamp, the best programmers were the ones who would perceiver. They weren’t necessarily the smartest students. Often, the smartest would burn out quicker because they are get used to win fast.

Another thing about geniuses which is bad, and which is outlined in the book Mindset: The New Psychology of Success, is that a genius who was successful might be afraid to take on a new risk for the fear of losing the prestige.

I saw plenty of senior software engineers who won’t consider any new technology mostly because they didn’t know it, NOT because they had any good arguments. To give you an example, one Java architect with a decade of experience in J2EE was telling me that putting HTML in JavaScript is a violation of separation of concerns when we talked about JSX and introducing React components to the company. That was three years ago and it’s funny how React is now a de facto front-end library of choice.

I agree that hard work can beat smarts. The trick is to keep up the momentum to keep up the work. Most people quit to early. Of course, smart plus hard work is 10 times better.

On the other hand, very often the best code is the code you never wrote. Indeed, it’s often not necessary and even detrimental to future maintenance to spend 10 hours implementing a feature from scratch when you can download an npm module and configure it in 30 minutes (this is smart). On the other hand, those 10 hours will go a long way toward betterment of your understanding and skills (this is hard-working).

In the end, you don’t have to be a genius to be a programmer. Be smart and hard working instead. But if you are a genius, then don’t afraid of failure (because it’s learning) or tedious work.

Courses on Node.js, React and JavaScript. Become an expert with my comprehensive Node.js, React.js and JavaScript courses.

Learn Full Stack Javascript →

— Azat Mardan

https://www.linkedin.com/in/azatm
To contact Azat, the main author of this blog, submit the contact form.

Also, make sure to get 3 amazing resources to FREE when you sign up for the newsletter.

Simple. Easy.

No commitment.

Originally published at webapplog.com on April 30, 2018.

Are programmers born or made? It depends. In 2010s, programming is so much easier than it used to be in 2000s. More and more gurus and dev bootcamp founders proclaim that programmers can be made.

I won’t say programmers are made. My answer: it depends. Instead of thinking programmers are made, utilize whatever belief is more useful to you.

If you are starting on the programming path later in your life as a second (or third, or fourth) career choice, then thinking programmers are born is detrimental! Why would you do such a thing?

Think and truly believe that programmers are made, if you want to succeed as a programmer. That’s because every time you encounter an issue, you’ll be inclined to work through it when you think that NOW you are a programmer.

On the contrary, you will be more successful thinking programmers are born, if you has been programming from your teens and programming is the only career you ever had. The reason is when you encounter a problem, you’ll be forced to find a solution because that’s what you do. You are a programmer and alway was. You have to come up with the answer because you are a programmer. You’ll value your job and think it’s your missing to write great software, because you won a lucky lottery.

If we dig deeper, programmer are not born. No one in the hospital looks at a child and says “congratulations, that’s a programmer”, “you are luckliy, that’s a QA engineer”, “sorry, that’s a designer”. No. Most likely it’s a dumb luck. The kid got a computer as an early age and tried programming and liked it. Then he got more experience and made himself into a programmer. So born is actually made just at an earlier age.

In any case, think and believe whatever is more useful to you in your career and life. Not what someone else tells you.

Original post: https://webapplog.com/born-vs-made-programmers/

It’s kind of depressing. Take a look at this page. Nodejitsu, which was one of the first Node PaaS solutions, says it joins GoDaddy which is just an hiring of the team. They refer to Modulus which you think is another PaaS, but it’s not. It’s a very poorly-done website for what looks like some consulting company in the trading space. The link to the blog post is 404 Not Found.

The previous edition of Full Stack JavaScript was published in 2015. In three years, a lot of companies either sold for scraps or closed or both (sold then closed the projects). It’s very refreshing to see this trend in a long span of several years.

Every market goes through cycles. First there’s an expansion with various offerings and then there’s a retraction with just a few major players dominating. It’s a winner takes all economy. Amazon, Google, Microsoft and IBM are serving major cloud services now. Startups are hard and most of them don’t know how execute. VCs are pushing for startups to spend more to acquire marketshare. The big companies have more leverage and more room for mistakes. They can just buy the best startup in the end. Is it still worth trying to start your tech startup in 2018? Probably not unless it’s something completely new. You can’t drive forward while looking in a rear view mirror.

IT Consolidation was originally published in Software Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bitcoin price was rising like a crazy and that’s why more and more people are interested in it. I did my informal survey every time I was at a restaurant or taxi by asking waiters and taxi drivers if they invested in Bitcoin. Most of them said no or “what is bitcoin?”, so this article is for them.

Why Blockchain is The Future

Blockchain is the technology behind Bitcoin, Ethereum and pretty much all other 40+ cryptocurrencies. Blockchain is an open source (like free) tech and it’s finding use in corporations and probably governments and big banks will roll out their own semi-decentralized blockchains. Blockchain is a very advanced and good technology. Everyone agrees on that, even people who bash Bitcoin and think Bitcoin is a scam.

At the heart of the Blockchain’s tech lies proof-of-work or PoW (although other algorithms like proof-of-stake are becoming more popular due to their lower demand on computation and thus electricity). PoW is when other independent computers (miners) confirms your transactions (e.g., send 0.005 BTC from your address to address).

That’s why in blockchain and cryptocurrencies there’s no need for a server or any central organization. Having a decentralized currency eliminates the need to trust one entity (federal government, central bank, corporation). Look at the Facebook and Twitter censorship or failures of Amazon Web Services or Google privacy violations, and you’ll understand the appeal of the decentralization.

Under the hood, this network of miners work to confirm transactions and earn crypto rewards for that. They consume a lot of electricity because it takes time to confirm an encrypted/signed with a private key transaction which makes blockchain secure. All transactions are open to see for anyone in what is called public ledger. However who has what address is anonymized (hidden), because anyone can create an address and a private key pair which all they need to send or receive money. An address or a key look like a long string of mixed up characters. You can even print them on a piece of paper if you’re afraid of a hacker stealing the keys from a digital wallet (which happens very often to people who rely not on local but on wallets with supposedly secure exchanges and companies).

What is Bitcoin and How to Invest and Short It

Bitcoin is one of the earliest (first?) real-world applications of Blockchain. Bitcoin (BTC) is the most popular and thus most expensive. Someone could have made 4x in two months by buying BTC for $5K and selling at $20K. If you want to buy and hold, then there are multiple ways to get a Bitcoin: buy from miners, buy from other bitcoin investors, buy from an exchange (like a middleman), mine your own. Buying from an exchange is the easiest and the most secure (mining is slow while dealing without a middleman can lead to you becoming a victim of a fraud). Coinbase is one of such exchanges. You sign up, connect your bank account and ready to buy BTC. Coinbase uses GDAX which you can use as well to avoid paying fees on Coinbase but GDAX will take some learning while Coinbase can be used by your grandpa. That’s for buying long (betting on the price rising).

If you think that Bitcoin is a scam and/or a pyramid scheme (as do I), then you are wondering how to short (bet on the price going down). I spent a few hours and learned how to do just that so you can save time and learn from me. I made two short orders and lost $30 in the process (BTC was going up). I used Kraken.

The way shorting on Kraken works is that after you log in and verify your identity, create a sell order with some leverage like 1, 2, 3, 4 or 5. This will make you borrow a BTC from the Kraken exchange. Of course you pay an interest to Kraken on an hourly basis so make sure you know that the price will go down in 1–2 days not 1–2 months (hard, I know!). You sell the borrowed BTC to the market and then when you close or settle the order, you buy at the lower market.

All this is done automatically by Kraken. You just create a sell order with a leverage and then you will see your profit (or loss like I did). You can trade other crypo on Kraken including myriads of clones, jokes (and/or scams?) cryptos like Bitcoin Cash, Dogecoin, etc.

Kraken software is very shitty so try sending your orders a few times until you see it in the list of orders. I had to do that and I also had to refresh my browser like a maniac because their website was unavailable. Another annoying fact with Kraken is that they call BTC XBT or some made-up bullshit like that.

Why Ethereum Is Better than Bitcoin

While Bitcoin is popular, the downsides are: it’s slow (Litecoin is faster) and it’s just a number. Ethereum (ETH) on the other hand is not just a number. Ethereum is like a computer. Anyone can put a program into its network and the program (dapp) will live there forever and be transparent and work. Dapps can do anything: crowdfunding (ICO), insurance, file storage, betting, settlement, etc. They are decentralized (d in dapps) which makes them more trustworthy since there’s no single entity anyone must trust. Miners power the network and verify and run dapps. Users use Mist or MetaMask to interact with dapps.

People pay to “run” dapps in the Ethereum network (big computer) or just to buy ETH which is like buying BTC. I built an Ethereum wallet which can send money (and create dapps) in just a few hours. I used JavaScript, Infura provider and the web3 library. The language to build dapp is Solidity.

You can buy ETH on Coinbase, GDAX or Kraken while it’s still low (relative to BTC). Don’t sell or mortgage your house though. Speculate (this is a speculation since crypot don’t produce dividends or rent) only with the money you can lose. (Disclaimer: I’m not a financial adviser and I lost money on shorting so take my advise for what it’s worth which is free as this blog post.)

If you want to invest in BTC better go to Las Vegas (in my humble opinion, investing in Bitcoin is like gambling cause almost no one knows what will happen). If you want to invest in educating yourself and building tools, exchanges and apps on blockchain, then you can make a fortune cause most of the software and tools suck.

If you’re a software developer with a few years of experience, and you’re new to Node.js or web development, join popular instructor Benjamin Lin and author and founder of Node University Azat Mardan for Introduction to Node.js, now available on edX. In just a few hours (and using the latest materials), make the leap from desktop apps, and see how easy and fast it is to get started on Node.js. Plus, who better to learn from than the always-entertaining Benjamin and his colleague Azat, who has written more than a dozen books on Node.js?

Node.js is popular because it’s simple, has a low footprint, is built for networking, and is easily configurable. Go beyond the simple HTML page, and create a full-fledged web application. Set up a web server, interact with a database, and much more! Benjamin and Azat step you through installation — just bring your computer, an Internet connection, and a web browser. Get the basics of Node.js and its core modules. Import additional modules, and configure your project using npm. Then see how to use Express to set up a web server and how to interact with a MongoDB database using Mongoose.

By the end of the course, you’ll have seen eight major demonstrations and you’ll have created several real-world projects, including a web scraper, a blogging API, and a database migration script. Each demo has accompanying hands-on labs, examples, and practical applications.

The ability to use one language across an entire stack has been described as “pure magic!” Put this magic to work for you! Get productive with Node.js, and use your new skills right away!

Learn how to:

• Set up a Node.js project using npm
• Use the Node.js core modules
• Use Express to set up a web server
• Use MongoDB to store data in a database
• Use Mongoose to model database schemas

Enroll today! https://www.edx.org/course/introduction-nodejs-microsoft-dev283x

Become an expert with my comprehensive
Node.js, React.js and JavaScript courses.

Learn Full Stack Javascript →

— Azat Mardan

https://www.linkedin.com/in/azatm
To contact Azat, the main author of this blog, submit the contact form.

Also, make sure to get 3 amazing resources to FREE when you sign up for the newsletter.

Simple. Easy.

No commitment.

Originally published at webapplog.com on November 21, 2017.

This is an excerpt from the book React Quickly, available at manning.com

This article covers how to capture text input and input via other form elements like <input>, <textarea>, and <option>. Working with them is paramount to web development because they allow our applications to receive data (e.g. text) and actions (e.g. clicks) from users.

Recommended Way of Working with Forms in React

In regular HTML, when we work with an input element, the page’s DOM maintains that element’s value in its DOM node. It’s possible to access the value via methods like: document.getElementById(‘email’).value or by using jQuery methods. The DOM is our storage.

In React, when working with forms or any other user input fields such as standalone text fields or buttons, developers have an interesting problem to solve. From React’s documentation: “React components must represent the state of the view at any point in time and not only at initialization time.” React is all about keeping things simple by using declarative style to describe UIs. React describes the UI, its end stage, and how it should look.

Can you spot a conflict? In the traditional HTML form elements, the state of the elements will change with the user input. React uses a declarative approach to describe the UI. The input needs to be dynamic to reflect the state properly.

If developers opt NOT to maintain the component state (in JavaScript), nor sync it with the view, then it creates problems — there might be a situation when internal state and view are different and React won’t know about changed state. This can lead to all sorts of trouble, and mitigates the simple philosophy of React. The best practice is to keep React’s render() as close to the real DOM as possible, and that includes the data in the form elements.

Consider this example of a text input field. React must include the new value in its render() for that component. Consequently, we need to set the value for our element to new value using value. If we implement an <input> field as we always did in HTML, React will keep the render() in sync with the real DOM. React won’t allow users to change the value. Try it yourself. It might feel nuts but it’s the appropriate behavior for React!

render() {

  return <input type=”text” name=”title” value=”Mr.” />

}

The code above represents the view at any state, and the value will always be “Mr.”. With input fields, they must change in response to the user keystrokes. Given these points, let’s make the value dynamic.

This is a better implementation, because it’ll be updated from the state:

render() {

  return <input type=”text” name=”title” value={this.state.title} />

}

What is the value of state? React won’t know about users typing in the form elements. Developers need to implement an event handler to capture changes with onChange.

handleChange(event) {

  this.setState({title: event.target.value})

}

render() {

  return <input type=”text” name=”title” value={this.state.title} 
    onChange={this.handleChange.bind(this)}/>

}

Given these points, the best practice is for developers to implement the following things to sync the internal state with the view (Figure 1):

1. Define elements in render() using values from state.

2. Capture changes of a form element using onChange() as they happen.

3. Update the internal state in event handler.

4. New values are saved in state and then the view is updated by a new render().

Figure 1: Capturing changes in input and applying to state

It might seem like a lot of work at first glance, but I hope that by using React more, you’ll appreciate this approach. It’s called a one-way binding because state only changes views. There’s no trip back, only a one-way trip from state to view. With one-way binding, a library won’t update state (or model) automatically. One of the main benefits of one-way binding is that it removes complexity when working with large apps where many views can implicitly update many states (data models) and vice versa — Figure 2.

Simple doesn’t always mean less code. Sometimes, like in this case, developers must write extra code to manually set the data from event handlers to the state (which is rendered to view). But this approach tends to be superior when it comes to complex user interfaces and single-page applications with a myriad of views and states. To put it concisely: simple isn’t always easy.

Figure 2: One-way vs two-way binding

Conversely, a two-way binding allows views to change states automatically without developers explicitly implementing it. The two-way binding is how Angular 1 works. Interestingly, Angular 2 borrowed the concept of one-way binding from React and made it the default (you can still have two-way binding explicitly).

For this reason, we’ll cover the recommended approach of working with forms first. It’s called controlled components and it ensures that the internal component state is always in sync with the view. The alternative approach is uncontrolled component.

So far, we’ve learned the best practice for working with input fields in React, which is to capture the change and apply it to state as depicted in Figure 1 (input to changed view). Next, let’s look at how we define a form and its elements.

Defining Form and its Events in React

We’ll start with the <form> element. Typically, we don’t want our input elements hanging randomly in DOM. This can turn bad if we have many functionally different sets of inputs. Instead, we wrap input elements that share a common purpose in a <form></form> element.

Having a <form> wrapper isn’t necessary. It’s totally fine to use form elements by themselves in simple user interfaces. In more complex UIs, developers might have multiple groups of elements on a single page. In this case, it’s wise to use <form> for each group. React’s <form> is rendered at an HTML <form>, and whatever rules we have apply to React’s <form> element too. According to the HTML5 spec, developers shouldn’t nest forms (it says content is flow content, but with no <form> element descendants).

The form element itself can have events. React supports three events for forms in addition to standard React DOM events:

• onChange: Fires when there’s a change in any of the form’s input elements.
• onInput: Fires for each change in <textarea> and <input>elements values. React team doesn’t recommend using it (see below).
• onSubmit: Fires when the form is submitted, usually by pressing enter.

onChange vs. onInput

React’s onChange fires on every change in contrast to the DOM’s change event, which might not fire on each value change, but fires on lost focus. For example, for <input type=”text”> a user can be typing with no onChange and only after the user presses tab or clicks away with his/her mouse to another element (lost focus) will the onChange be fired in HTML (regular browser event). As mentioned earlier, in React, onChange fires on each keystroke, not only on lost focus.

On the other hand, onInput in React is a wrapper for the DOM’s onInput which fires on each change. Therefore, the React team recommends using onChange over onInput. The bottom line is that React’s onChange works differently than onChange in HTML, in that it’s more consistent (and more like HTML’s onInput). onChange is triggered on every change and not on the loss of focus.

The recommended approach in React is to use onChange and onInput only when you need to access native behavior for the onInput event. The reason is that React’s onChange wrapper behavior provides consistency.

Using Form Events

In addition to the three events listed above, the <form> can have standard React events such as onKeyUp or onClick. Using form events might come in handy when we need to capture a specific event for the entire form (a group of input elements).

For example, it’s good UX to allow users to submit data on hitting enter (assuming you’re not in the textarea field, in which case enter should create a new line). We can listen to the form submit event by creating an event listener which triggers this.handleSubmit().

handleSubmit(event) {

…

}

render() {

  return (
    <form onSubmit={this.handleSubmit}>

      <input type=”text” name=”email” />

    </form>
  )

}

Please note: We’ll need to implement the handleSubmit function outside of render(), as we’d do with any other event. There’s no naming convention which React requires, and you can name the event handler anything you wish as long as it’s understandable and consistent. For now, we’ll stick with the most popular convention to prefix the event handler with the word “handle” to distinguish it from regular class methods.

As a reminder, don’t invoke a method (don’t put parenthesis), and don’t use double quotes around the curly braces (right way: EVENT={this.METHOD}) when setting the event handler. In React, we pass definition of the function, not it’s result, and we use curly braces as values of the JSX attributes.

Another way to implement the form submission on enter is by manually listening to key up event (onKeyUp) and checking for the key code (13 for enter).

handleKeyUp(event) {

  if (event.keyCode == 13) return this.sendData()

}

render() {

  return <form onKeyUp={this.handleKeyUp}>

    …

  </form>

}

Please note that the sendData method is implemented somewhere else in the code. Also, we’ll need to bind(this) event handler in constructor().

To summarize, in React we can have events on the form element, not only on individual elements in the form.

Note: The source code for the examples in this article is in the ch04 folder of the GitHub repository azat-co/react-quickly. And some demos can be found at http://reactquickly.co/demos.

That’s all for this article, for more on React and its myriad uses check out React Quickly at manning.com.

DISCLOSURE STATEMENT: These opinions are those of the author. Unless noted otherwise in this post, Capital One is not affiliated with, nor is it endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are the ownership of their respective owners. This article is © 2017 Capital One.

How to Work with Forms, Inputs and Events in React was originally published in Capital One Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Technology is the fastest growing sector in the job market. Software, cloud and automation replace traditional jobs of factory workers, secretaries and service workers. Software and technology companies are the most valued by the stock market and investors. Founders of these companies are one of the richest people in the world. Startup founders and nerds are new role models for kids.

But what if you are not coding prodigy like Mark Zuckerberg or Bill Gates who started coding in their teens. What if you don’t really enjoy coding that much or maybe you are more of a peoples or a liberal arts type of a person? Do you prohibited from a tech industry? Most people don’t know that they are plenty of jobs in the tech industry which do not require coding.

Of course, you cannot be a clueless pumpkin and know nothing about tech. You still have to be technically literate and know what is a database or an API is, but you’ll mainly be leveraging your existing skills from another industry, not starting from a scratch learning coding. (Learning coding when you are in 50s are still possible. I saw it happen a Hack Reactor where I taught. But let’s admit, on average the wits become duller with age, not sharper.)

Here are seven (7) such jobs which do not require coding or deep technical expertise but can be interesting, fulfilling, and well-paid.

1. Program Manager
2. Product Manager/Owner
3. Scrum Master
4. Designer
5. User Researcher
6. Recruiter
7. Tech Writer

Let’s me give you some brief insight into each of them.

Program Manager

Program Manager (not to confuse with product or project manager) is a person who works on 3–5 projects at a time to make sure all the dependencies are resolved on time, and there are no obstacle to deliver products on time. A typical day of a Program Manager is spent in various meetings listening to the status updates to make sure everything is running smoothly. Think about this job as being an overseer of the product schedule and communicator between various teams. You are a hero who saves the world, albeit an undercover (like Clark Kent) and sometimes under-appreciated one (like Dr Watson).

The upside is that you will be rarely bored. There’s always something happening and you’ll get to meet a lot of teams and people in various organizations within your company. If you thrive on juggling multiple tasks, great with scheduling and planning, if you hate boredom, then PM is a great role for you.

The downside is that there’s little to no authority meaning typically you don’t have any direct reports. You need to use your influence, charm and communications skills to “sell” involved on the right way to resolve conflicts and competing priorities.

Product Manager/Owner

Product Manager, or in some companies Product Owner, is often mistakenly dubbed “a CEO of a product”. Mistakenly because unlike a real CEO of a company you can’t hire or fire anyone. What you do is you take the vision or an idea and shape it into a real product by talking to software engineers and customers. You are at the intersection of business, customer and engineering. You do it by making sure the product is a money maker and strategically aligned with the company, and ends up being implemented as close as possible to what customer wants.

Upside is that it’s fulfilling to see shape a new product and see happy customer faces when they get it in their hands (or emails). The downside is that as in the Product Manager role, you rarely have any authority over engineering, design or anyone else. You need to drive the execution by influence without authority. There’s a healthy push-and-pull between PM and engineering with one trying to over engineer or cut corners (engineers), and other shooting for the stars or asking for insane deadlines.

PM is the fastest track into the senior leadership. If you can come up with a money-maker idea and bring it to the market, then that’s a great way to be promoted. Most of the VPs and C-level execs come from the PM background (others are from sales — another bread-winner role, and just recently from engineering as seen in Google and Microsoft).

Scrum Master

This role is very straightforward. You can read a book or get certified to know all about Scrum which is a methodology to build software products in an iterative fashion. Scrum is related to Agile. The Scrum concept is centered on fast feedback and constant learning and adjustment. Some big companies hire dedicated Scrum Masters to work on 3–5 projects while others just rotate engineers every two weeks. (I do not recommend having a software engineering manager or tech team lead being a Scrum Master.)

A typical day consists of “standups”, which are ironically almost always are sit down meetings or video conferences due to misunderstanding while they really should be just short 10–15 minute meetings. In these daily meetings each team member tells a status update. Scrum Master mainly helps to catalog progress, resolve blockers, organize tasks into a tracking system (like JIRA), and help with planning of the next sprint (1–2 week period).

Upside is that this job is relatively easy while the downside is that not all companies work in a true Agile (which is a parent concept of Scrum). Most companies adapt what I call waterfallagile where you have a far reaching deadline but try to work in sprints. This approach sucks. It can lead to stressful life right before the deadlines and eventually poorer product than in a true Agile. Sadly, most companies are very stubborn in their Agile mind set. Once they hired consultants to come and implement Agile and Scrum, these companies stop learning and adjusting the Agile process.

Designer

The designer job is very creative and artsy. You work closely with PM, customers and User Researcher which can inhibit the creativity by imposing certain requirements on your next masterpiece. Your job could vary from producing paper sketches to full blown app prototypes (which could often be built without coding or with minimal coding skills). It can be very non-technical or very technical depending on your preference and expertise. For example, you could start your career just with some basic illustrator skills and tools like Adobe Photoshop and over the years learn HTML and CSS (easy markup and styling languages) to help software engineers implement your designs exactly you want.

The upside is that you can get freelance work tomorrow. You can work remotely too. Or you can join a big company and work in a cool hip office in San Francisco. There are a lot of online tutorials to learn any of the design tools on websites like Udemy, Lynda, etc. You work will be seen by thousands or even millions of other people. You can be proud of it when you show it to your friends, casually drop in a conversation at a cocktail party or send a link to your parents. For example, when I worked at DocuSign, our design team did an amazing job. I’m very proud of the new DocuSign experience which we built, and mention how great it is at any opportunity… and especially to real estate agents who use some crap like RightSignature or EchoSign.

The downside is that you have to work closely with software engineers and this is not a joke. Software engineers can be jerks, but they’ll be the people who are supposed to implement your designs. Most of the times software engineers (at least the adequate ones) be happy to have your designs since they are not great at design themselves and understand that. Occasionally either from a lack of sleep, too much coffee or just being assholes, some software engineers will protest that a certain element is too hard to implement. Other times, or you’ll get an interpretation on your design, not exactly what you or customers wanted. Don’t get me wrong. Most of software engineers are wonderful human being but due to a healthy tension (which helps to make a better product) designers, QA engineers (a.k.a. tester) and engineers are the groups who have the most conflicts. (Though hating on extraverted, noisy and bro-like sales people bring these groups closer.)

User Researcher

User Researcher is a relatively new but highly important role. The main task is come up with better product and to test out prototypes and designs of new products to get customer feedback. For example at Capital One, we have a user research lab which is a room with one-way mirrors like in an episode of an investigation TV show. There are professional hidden cameras and microphones. People are paid a small reward ($25–100) to come to these studies. They spent an hour or so testing out a new product and your role is to document the findings and then communicate what’s working and what’s not to PMs, design and engineers.

User Research solves for better User Experience (UX) and also for not wasting time on something no one wants (comes from the Lean Startup concept). For example, better UX could be making a delete button accessible from the toolbar with one click instead of the submenu with confirmation which requires three clicks and thus has more friction. Amazon 1-Click is another example of brilliant UX which makes usage easer while bring Amazon bazzillions of added revenues.

The upside is that you help shape the product into a better one and prove or disprove hypothesis (hence the name: researcher). This job doesn’t require deep technical knowledge which makes this job ideal for an entry into the tech industry and a company. The downside is that now all companies and teams take UX seriously yet, but then do you really want to work in a such a backwards company? Probably not. Google, Amazon, Facebook, PayPal, Capital One and many others successful tech companies take UX seriously. Companies like that are a good place to work.

Recruiter

Recruiters find talent and depending on a company arrange interviews and facilitate hiring while big companies have separate roles for that. Your day is spent searching LinkedIn, GitHub and in emails and phone calls with prospective candidates. You need to be good at assessing people meaning you need to have at least the basic understanding of tech requirements for the job. You need to have a sense of the culture fit, and company and team goals. On the other hand, you need to be a good salesperson to be able to sell the candidate on your company and this role. Needless to say, networking and being a great communicator is paramount.

The downside and upside are the same: It’s a very tough and competitive hiring market meaning it’s hard to recruit but there’s a big demand for good recruiters (the bar is very low which makes it easy to be a good recruiter). Almost all companies have job openings. I suspect there’s an even negative employment rate as I’m sure some people have more than one job (one guy automated his job and did nothing for a few years). Also, you can freelance as an independent recruiter by making a killing on recruiting fees instead of getting a fixed salary. A single hire can bring you $10,000–20,000!

Tech Writer

A Tech Writer works on documentation, tutorials, press releases, help pages, and anything else which supports a product. Tech Writer needs a little bit more tech understanding than other jobs described in this article, but still it requires NO CODING, and you can enjoy the same awesome stock plan, health insurance and yoga classes as any one else in the company.

A typical day is spent in front of a computer typing away in an MS Word document, and occasionally in a Slack messenger to clarify a certain feature from a designer, PM or engineer. This job is a perfect fit if your English flows smoothly like mine, you like learning about tech (but not coding), you like helping users by providing them with an understandable English instead of “Error 50004”, and most importantly you are not annoyed by multiple text reviews, proofreading and typos (as I am).

The upside is that this job is perfect for introverted and remote workers (freelance or full-time). The downside is that you’ll need to become very proficient with tech terms and product features. Also, only medium and big size companies have dedicated Tech Writer roles. Startups can’t afford this role, so this task is done by either founders, admins, or engineers themselves (worst).

Wrap Up

This concludes the lucky seven list. All of this jobs can be a starting job in a tech industry. It’s very common to start in one role and then transition to something else. Don’t get stuck thinking you have to do one job for the rest of your life. Some of the roles are extroverted like a Recruiter (networking and cold calling skills help immensely) while other introverted like a Tech Writer (just find a quiet place, sit with the product and you are good to go). Start with something you feel interested about, and then you can ask to transfer to a new role in a year or two. It’s easier to move around within tech once you are in. Get you foot in the door first!

Tech industry is crashing many established industries like transportation, banking, travel, communication, entertainment and pretty much any other. Tech companies offer hip offices, best health insurance plans, stock options, retirement plans, unlimited vacations, pet-friendly environments, remote work, free juices, espresso coffee, organic snacks, gourmet meals, yoga classes, ping pong tables, foosballs, video games, and myriads of other perks. What is your excuse of not joining the ranks of the new elite now that you know seven jobs which don’t even require coding? Educate yourself more, polish your resume and get a job in tech!