开源日报 - Page 122 of 262

开源日报第555期：《我枯了 WamaCry》

21 9 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《我枯了 WamaCry》
今日推荐英文原文：《30 Ways Programmers Can Be Creative》

今日推荐开源项目：《我枯了 WamaCry》传送门：GitHub链接
推荐理由：给生活加上悲伤的色彩——假装让电脑中了病毒的项目。用法很简单，用这玩意作为某个文件的打开方式，就可以假装它被病毒锁住了，甚至你还能自定义病毒里要写的内容……用在整蛊等用途上效果极佳，如果你演技足够甚至可以以假乱真，只要别忘了仅供娱乐就好。

今日推荐英文原文：《30 Ways Programmers Can Be Creative》作者：Jun Wu
原文链接：https://medium.com/better-programming/30-ways-programmers-can-be-creative-6c10ddf2df4b
推荐理由：用于激发创造思维的一些问题
30 Ways Programmers Can Be Creative

Don’t just go through the motions of programming — create and architect
I’m a creative individual. When I was working in the corporate IT environment, I took every chance I could to be a nonconformist. Having said that, as a programmer, I also followed rules. Initially, I had to follow rules to learn from mentors. However, I also defied those rules when I wanted to implement a better idea. In my time away from the office, I defied the rules when I wanted to try (and sometimes fail miserably) to learn the best way of doing things.

One characteristic that allowed me to excel in programming is “problem-solving”. Ever since I was little, I looked at life as one giant “problem” to solve. Every day, what drives me is solving problems. If I didn’t have problems to solve, I would be miserable.

For me, every problem-solving opportunity is also an opportunity to create.

You may not agree with me. You may look at programming as actions composed of sequential steps. You may look at programming as a purely logical process. You also may tell me that one of the reasons you are attracted to programming is the “step-by-step” manner that all the “bricks” may be laid down in your castle of code. You’re a builder. You excel in getting projects done, shipped, tested, and released.

I’m all for that.

Nothing excites me more than seeing finished code organized, tested, ready for release.

Disclaimer: Through my coding adventures, working with different types of technical managers, I’ve extracted 30 ways that we all can be creative in our coding lives. These are just for inspiration. In your day to day life as a developer or a technical manager, you probably have a lot more. This article is meant to inspire all of us to think more about creativity in our day to day coding lives.
Creativity Implies Freedom. Freedom is Earned.
Development teams have a system of seniority. There are different levels of skillsets: junior developer, senior developer, architect, technical manager, etc. As you progress through your coding career, trust is earned at each stage. Once you demonstrate your competency the team will offer you more opportunities for independent work. As you work more independently, you can experiment more and creativity will come more naturally. If your creative ideas work consistently well you will probably be moved into roles that will allow you to make more creative decisions. (All of this is also dependent on company culture and team culture.)

Creativity is not handed out for free. Creativity comes with freedom that goes hand in hand with incremental demonstrations of competency.
The Start of Creativity
As a junior developer or a mid-level developer, creativity is everywhere to be found. Below is a list of casual but important decisions that can be made. These decisions all call for your creativity in finding the “best” solution.
- What’s the best stylistic considerations to follow for implementing this feature? (spacing, indentation, commenting, naming conventions)
- Should there be a design pattern used to implement a given feature? What’s the best one to use?
- What are some data structure choices that can be made? (hashtable, dictionary, array, list, etc..)
- What are some data type choices that can be made? (string, character array, int, float, etc..)
- Can any of the functions implemented be reusable?
- Are there too many lines of code?
- What’s the best design for handling exceptions?
- What’s the best way to handle garbage collection or memory usage?
- What are some unit tests that can be written for this feature? How do I write them?
- Whose code can I read to learn more? What should I learn next on my stack?
The Next Level of Creativity
As a senior developer, you’re already familiar with the full stack of technologies required in the development cycle. You’re also familiar with many issues that may creep up, both in the codebase, the development cycle, and the testing phase. You are not only skilled in figuring out the root cause of issues, but also on hand to make key design decisions for optimizations. You’re a leader that the junior developers look up to.
- Why did this developer implement the feature this way? What is the problem in the developer’s thinking? How can I help to steer the developer in the right direction?
- Why is this bug creeping up again? What is the root cause? Is this a design issue, implementation issues, or a testing issue? How should we fix it?
- Will this code be maintainable in the long run?
- Do we need all these patterns to implement this one feature?
- Have we made the wrong decision in our choice of infrastructure?
- Is performance tuning necessary for the messaging services, data retrieval/storage, etc..? How should we tune? What metrics to use for tuning?
- Are there any security concerns in the implementations?
- Can developers benefit from knowledge sharing? What kind of knowledge sharing is optimal?
- Is it time to refactor the codebase? How should we refactor some of it?
- What’s the best way to test? What does the testing plan look like?
The Final Level of Creativity
As a technical manager, you are participating in all levels of design and technical specifications for the projects you’re assigned. You setting technical limitations and expectations for your projects. You’re in charge of a team of senior and junior developers. Because you’re the leader, you need to take care of administrative tasks, work with clients, project management team, and technologists from other teams to figure out the best way to complete your projects. In all three silos, technical, management, and business, you need to be creative about your decisions.
- What Programming Language to use for a particular part of the system?
- What infrastructure resources do we need for the project?
- What are the trade-offs for data storage? How can we scale up or scale-out?
- What are the key design features that must be worked out with the architect? What technical specifications are needed for these key features?
- What are the technical limitations of the proposed business requirements?
- What are the budget concerns relating to the timeline, developers on the team, and other resources on the team?
- Is the codebase maintainable? Are there concerns with how the development cycle is run that affects codebase maintainability?
- How and when should work be assigned? How long are the sprints and the development cycles? When should code reviews happen? How should they happen?
- Which teams do you need to work with to acquire all the necessary resources for the project — requirements, budget, and infrastructure? What are the necessary networking steps to acquire these resources?
- What does the testing and sign off process look like? Who are the stakeholders affected? How should we notify them?
Every day we work as developers, senior developers, or technical managers, we make decisions large and small. All these decisions are opportunities to be creative. In being creative about our choices, we validate our knowledge and earn respect. If we’re proactive about seeking a better solution in all of our decisions, we’ll earn the freedom to be creative in our development teams. We don’t work entirely independently, but, we can be trusted to do self-driven quality work. On a development team, no matter what level of seniority we are at, we have opportunities to exercise our creativity and put it to good use.

Our jobs are not just jobs — they’re creative adventures.

What are you waiting for?
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第554期：《有来有回 reverse-interview》

20 9 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《有来有回 reverse-interview》
今日推荐英文原文：《Developers, Stop That Stressful Interview Preparation》

今日推荐开源项目：《有来有回 reverse-interview》传送门：GitHub链接
推荐理由：面试的时候对方会问你问题来决定你是否适合这个职位，而你当然也需要问对方一些问题来获得更细致的工作情报。这个项目是一个面试时你可以回问对方的问题合集，虽然你肯定确定已经一定只能选择其中的一些去询问（真的有很多细节可以去问），但是不放过任何获得情报的机会总是没错的，足够的情报能让你在开始一份可能的工作之前对它有个大概的认识和心理准备。
今日推荐英文原文：《Developers, Stop That Stressful Interview Preparation》作者：Pen Magnet
原文链接：https://medium.com/better-programming/developers-stop-that-stressful-interview-preparation-dd387d5b16fc
推荐理由：不要把精力都压在应对面试上，这些终究只是加入战场前的训练赛而已
Developers, Stop That Stressful Interview Preparation

Instead, be prepared with real software skills. Your dream tech employer will lay you off sooner than you might think
A couple of months back, my friend asked me about Uber interview guidelines. I shared with him some links from the web, especially some cool videos like this(https://www.youtube.com/watch?v=umWABit-wbk) I found from 30 seconds of googling.

He thanked me but said programming questions were too stressful for him, given the amount of time allowed.

I asked him the source of his interview preparation, and he shared this link:https://github.com/rishabh115/Interview-Questions/tree/master/Uber

I freaked out looking at the star count!

In fact, I was jealous. In my lifetime, I had produced and open-sourced components that saved me weeks of work, but I never reached a 50-star count on Github!

Before hanging up, he said he would pay some academy to train for the interview. I felt it would increase his investments, and thus, the stress.

Besides, it was unnecessary. After all, coding questions required time to practice, where was the problem? To that, he replied that the academy environment would give him some peers to measure against.

My final words to him were: “That’s whole lot of effort you are putting after Uber. It better be worth it!”

He never made it to Uber but ended up joining some other company.

When I read the news about the layoff of Uber engineers(https://techcrunch.com/2019/09/10/uber-lays-off-435-people-across-engineering-and-product-teams/), I was reminded of his struggle, and I thought to myself:

If he would have made it, would it all be really worth it?
Software Interview Preparation is a Millennial Obsession
Interview preparation for flagship tech companies has become a millennial obsession since the last decade and is rapidly spreading among Gen Z too.

The race to get hired by FAAMG was already hot in the last decade, but it’s far too competitive chasing Uber, Airbnb, Netflix, and Lyft too.
- Awesome Interview Questions(https://github.com/MaximAbramchuck/awesome-interview-questions), a github repo having list of popular interview questions, has 29k+ stars as of this writing.
- Coding Interview University(https://github.com/jwasham/coding-interview-university), somewhat more of a resourceful place, has 89k+ stars.
- Nick Dimitrov, an ex-Amazon AirBNB host offers an Amazon interview preparation session(https://qz.com/work/1693568/airbnb-experience-host-offers-amazon-job-interview-prep-for-5300/) to all his guests. The listing sells for $4,497/person and is part of a two-part interview-training series costing $5,294 total.
Due to such enormous attention, developers are chasing competitive programming sites — the modern mental gyms to get into top-tier software firms.

Imagine trying to solve 698 different array sorting problems to achieve better handle score on HackerRank/TopCoder/Codechef.

It feels great to get hired by one of the giants making TechCrunch headlines, but one really wonders what they end up delivering past that point. The real questions to ask are:
- How many actually end up designing core features of their flagship product using skills LeetCode taught them?
- How many are involved in designing entire product roadmaps (rather than piecemeal deliveries of smaller features)?
- How many end up starting their own ventures changing the world again?
- How many end up preparing for an even bigger paycheck, leveraging flextime sleeping in a nap pod?
The Other Side of the Wall
On the other side, though, is the bigger number of devs who failed to win this race to top-tier firms.

Simply because they could not sort that array in the given 30-minute timeline (they actually took 31).

They end up joining second-rung IT corporations, billing for every minute yet producing meaningful software, going through hell during the entire product lifecycle.

Simply because they missed out on that one LeetCode question during the interview prep.

Sometimes, they keep chasing that same dream for their lifetime. They eventually achieve it too, rarely realizing what else they could have done had they not chased it in the first place.

This disparity is the mother of intense stress that is born out of software interview preparation.
But the Happier Lot Isn’t Necessarily Lucky
Especially when the bell tolls for them. When layoffs happen.

Historically, being laid off was a matter of shame for workers. At that time, it was a matter of more shame for the employer too. The resulting stress and agony to the worker has been known to have long-lasting psychological impacts.

But since the1980s, after Neutron Jack, former CEO of GE, popularized them, layoffs became a norm. In other words, they became less of a taboo on employers’ shamelessness compass.

Tech industry, though, didn’t have its fair share of layoffs barring glaring example of Nokia, who handled it quite well for employees. Nokia paid huge sums toward retraining and severance. Top Nokia executives even helped setting aside startup money toward building newer ventures that could act as shock absorbers.

IBM, Intel, Qualcomm, Snapchat, Yahoo, Verizon, AOL all have fired people in recent years, but they were less noticeable due to smaller layoff volumes.

And they all were dream companies for developers in their respective times.
When It Gets Worse
Layoffs are not necessarily born out of losses. It is completely possible that you are laid off and the guy next to your cubicle is given a Porsche despite performing poorer than you.

Laws around layoffs allow a company to fire people even if their smallest department are making losses while bigger, peer ones are doing completely fine.

Companies in Uber generation have been taking advantage of every law around hiring to cut the corners: exploiting contractors, hiring and firing en masse.

Layoffs do not necessarily add up to cut their long-term losses, as anyone can see it obviously, but they act as an eyewash to panicking investors and media. They save the stocks from plummeting, thus putting a stop on founders’ depleting fortunes (that were created from zilch personal investments).

When such layoffs are endorsed/neglected by legal and governmental framework, their founders become flag-bearers of personal wealth creation benchmarks:
- Raise by 1000x valuations
- Hire in thousands and flood media feeds with revolution stories
- Wait until balance sheets show up with losses, keep selling their own stakes as and when term sheets allow
- If products start profiting, hire even more, spawn more verticles, instead of rewarding the original profit-maker developers
- At the slightest sign of losses in revenue predictions, fire people as soon as stocks start plummeting.
The worst-case paradoxical scenario of layoff is visible in the software industry because it is the only industry where you work toward your own obsolescence.

Once you deliver a product, the company can keep reaping its profit by hiring 10 customer care reps from Asia, all employed from your one salary.

As a software engineer, you can’t control when you will be laid off, but you can surely control how to deal with it — at least psychologically.
How Programmers Can Get Rid of This Stress?
Stop targeting flagship companies on a stressful level. Stop being part of the rat race.

If you love reading Cracking the Code Interview, it’s totally fine. If you love getting higher ranks at TopCoder, go for it.

But do it for the sake of love of programming. Do it for yourself. Do it to make your present work deliverable.

It will inflate your perception of your self-worth and help your future startup endeavors.

Expect more from you to create world-class software. Learning how to sort an array 59 different ways isn’t going to give you that.

Doing a full project worth completing from scratch will make you a more complete developer than 1,000 Leetcode assignments.

Do not chase a certain company who can fire you any Friday at a time when you have no way other than scheduling some more interviews as your severances run out.
Conclusion
The easy way is in front of you. Today’s FAAMG, however high on their hiring spree, can be disrupted and defeated by tomorrow’s unicorns.

The midnight oil you burn after stressful interview preparation may not give you that cushy nap pod forever. Instead, build your software skills around your favorite side project.

Instead of mindless interview preparation chasing FAAMG, it can support you during the dreaded layoff and buy you 1,000 nap pods for your employees someday. Who knows?
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第553期：《受苦 dark-souls-cheat-sheet》

19 9 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《受苦 dark-souls-cheat-sheet》
今日推荐英文原文：《The Most Common Pitfalls for an Inexperienced Developer》

今日推荐开源项目：《受苦 dark-souls-cheat-sheet》传送门：GitHub链接
推荐理由：说到高难度的受苦游戏，黑暗之魂肯定榜上有名。要想挑战这类游戏，充足的时间，足够快的反应和好运气都是相当重要的——国庆节兴许就是个好机会。这个项目是黑暗之魂的记录表，上面记录了游戏的流程和你能捡到的道具等，从黑魂开始接触受苦游戏兴许是个不错的开端，但是别忘了假期有限，请勿头铁，量力而行。
今日推荐英文原文：《The Most Common Pitfalls for an Inexperienced Developer》作者：Daan
原文链接：https://medium.com/better-programming/the-most-common-pitfalls-for-an-inexperienced-developer-c3636a1b5656
推荐理由：初学者可能犯下的一些错误，最要命的估计就是最后一条——技术可不能解决一切问题
The Most Common Pitfalls for an Inexperienced Developer

Don’t fall into the same traps as most developers
Experience is the name we give to our mistakes, according to Oscar Wilde. So, as you can imagine, developers with little experience haven’t yet hit the most common pitfalls. In this article I will show you some of these most common pitfalls, so you don’t have to fall into the same traps.

Most developers have probably fallen into at least one of these traps. Look at this article as a piece of advice, written from my experience, which you can benefit from — especially when you’re a relatively inexperienced developer.
Reimplementing Code That’s Already Available in the API
Most developers use some sort of framework to make their life easier. For an inexperienced developer new to the framework, it can be hard to know everything that is available in the API of the framework.

This often results in some kind of reimplementation of code that is already available in the API. Inexperienced developers are more likely to do this for two reasons.

Due to a lack of experience, the inexperienced developer doesn’t know everything that is available out of the box in the API. This leads to time being wasted on producing code that already exists in the framework. Their lack of experience also leads to them not using the framework’s full potential.

The second reason inexperienced developers often reimplement code is that they do not know where to look for in the documentation. Or even worse, they don’t look at the documentation at all.

This is a pitfall for inexperienced developers because it seems so tempting to just recreate the same function. Some functions only take a few lines of code to recreate. Plus it doesn’t take much time to write those few lines of code. But rewriting the same code has downsides. Double (untested) code is being introduced in the codebase. And the code gets more complex since a new function got introduced. Other developers are unfamiliar with that function and won’t understand why that function is introduced. Overall the complexity increases, which is something that you don’t want to do without good reason.
Don’t Make Things Unnecessarily Complex
Sometimes developers get in over their heads. The problem with this is that only experienced developers know when to admit it. Where experienced developers try to keep things as simple as possible, inexperienced developers tend to overdo things.

One of the reasons for this is that inexperienced developers will try to prove themselves to the rest of the team. They do this with all kinds of fancy stuff like quirky one-liners and overly complex abstractions. Technical debt is being added unnecessarily.

This pitfall will make the code more complex. Try to keep things as simple as possible. Experienced developers follow the KISS principle: Keep it simple, stupid. By adding technical debt code gets less readable and gets harder to maintain.
Silently Swallowing Errors
Silently swallowing errors is a mistake I’ve seen plenty of times from inexperienced developers.

A relatively inexperienced developer was working on a fix for a bug: a query that got executed wasn’t valid. The query was expecting a numeric value to check if a product was still in stock.
```
SELECT * FROM Products WHERE amountInStock > [numeric value]
```
The bug occurred because a numeric value wasn’t passed to the query. Instead, it got passed a null value. So the query looked like this:
```
SELECT * FROM Products WHERE amountInStock >
```
This triggered an error, of course. The inexperienced developer “fixed” the bug by typecasting the variable that got passed to the query to an integer. This made the syntax of the query valid but didn’t solve the problem.

Instead of tracking down the source of the problem, the inexperienced developer chose to “fix” the bug at the deepest level that was possible — entirely without bad intentions.

The correct way to fix this bug was by tracking down why a null value got passed to the query and fix that. One cause for the problem could be that the API that gives information about the stock was not available. If that’s the case the query probably shouldn’t be executed. The actual problem could be something completely different than a query not working properly.

By silently swallowing the error the real cause of this bug would have never been found. The “bugfix” that was implemented by the inexperienced developer was fine from a syntax perspective but would have swallowed the real error.
Overconfidence
Ask an overconfident inexperienced developer how long a task or user story will take and he’ll tell you the shortest time possible. If you ask the overconfident developer if he’s written some tests, he will tell you that there is no need to. The code is bug-free and it is impossible that it will break.

If you think you know it all when working on your first job as a developer, you’re wrong. If you don’t know what you don’t know, you don’t know how much you’re missing. This is where most inexperienced developers struggle.

Be humble and open to constructive criticism. Take advice from the more experienced developers. This will help you grow as a developer. Having confidence is good, but overconfidence will work against you.
Only Testing the Happy Path Scenario
Inexperienced developers often focus on just delivering the functionality or user story. This is what is known as following the happy path. The delivery of the functionality or user story should come with tests. This another place we see a difference between inexperienced and experienced developers: inexperienced developers only test what users are supposed to do; more experienced developers will also write tests for edge cases.

Only testing the happy path scenario is naive. Users are unpredictable — you need to test more than just the happy path scenario.
Switching Tools
Having the right tools and knowing how to use them can save you a lot of time on a daily basis. You should really take some time to find the right tools. When you are looking for tools, you should pick tools that do what they promise.

If you have the right tools, you should stick with them. Don’t switch tools every week. It takes time to get to know the tools and master them.

You should also invest in a good IDE since this is where you will spend most of your time. Learn the keyboard shortcuts and learn how to use code snippets. Create your own code snippets to speed up routine tasks.

Furthermore, you should learn how to debug. Pick an IDE that has some sort of debugger so that you can see the values of all the variables that are being used. This will give you a much better grasp of what is going on and will save you a lot of time debugging.
Focussed on the Tech and Not the Business
Inexperienced developers have not mastered their tech stack yet. And most of these developers tend to be so focused on learning the tech stack that the business gets out of sight. On the journey to becoming a master of your tech stack, it’s important to keep the business in mind. Why are you building this?

Some developers are only interested in the technical aspects of their job. They don’t care about the business or the economic factors that justify their job’s existence.

Is what you’re working on creating value for the business or are you spending too much time on something that doesn’t really matter? It’s an important question to ask yourself.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第552期：《更新日志 keep-a-changelog》

18 9 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《更新日志 keep-a-changelog》
今日推荐英文原文：《Four Ways to Know if You’re a Great Software Engineer》

今日推荐开源项目：《更新日志 keep-a-changelog》传送门：GitHub链接
推荐理由：但凡稍微活过些日子的软件应该都或多或少经历过了几次更新，而更新的多了，记得整理好更新日志就显得格外重要。指望对比源代码来知道哪更新了是不现实的事情，更新者应当准备一份面向人类的更新日志以方便阅读，这个项目就很好的指出了这一点——千万不要以为一个人就能把这种事情抛之脑后，尽早养成良好的习惯至关重要，而且你也不知道三百年后你会不会重新翻出一个之前旧玩具软件来重新加工。
今日推荐英文原文：《Four Ways to Know if You’re a Great Software Engineer》作者：Indrek Lasn
原文链接：https://medium.com/better-programming/4-tells-whether-youre-a-great-software-engineer-b0e496ed8f3b
推荐理由：这几点也可以作为一个努力的方向，用来找出适合自己而又有效的行动方式
Four Ways to Know if You’re a Great Software Engineer

What’s the universal measurement of a great software engineer?
Software engineering is the art of crafting beautiful software. What is beautiful software? Some might say beautiful software looks aesthetically pleasing and feels intuitive, others might agree that beautiful software equals coherent and logical code. There’s no right or wrong here, being a good software engineer is up to interpretation. Here are my key takes on what makes someone a great engineer.
Fun to Work With
You’re the first to arrive at the office at 7:30 AM and sit down to sip your morning coffee while reading the latest scandals around the globe, with the occasional small dose of programming and startup news. You feel good and feel ready to crush the day. You open up Github and start to review your previous pull request, only to find your teammate nit-picking on your variable naming, semi-colon insertions, and other trivialities, while completely ignoring the feature you implemented without any issues.

Photo by Allie Smith on Unsplash

Don’t be the guy to annoy your teammates. It’s fine to have standards, but such standards should be clearly defined and agreed on. If you argue about preferences, use prettier with ESLint. The two previous tools let teams agree on a standard while maintaining coding flavor.

Being a fun person to work with is absolutely crucial to being a great software engineer. Many engineers think that their code speaks for themselves. While we all admire great code, don’t be a jerk, especially if you’re a senior engineer. A great engineer should be fun to work with, non-lethargic, and ready to take on challenges. Not everyone can do it, but at least try. I’m often lethargic myself, but I try not to be. No matter how technically brilliant you are, you’ll always be limited by your ability to communicate.
“A rational person can find peace by cultivating indifference to things outside of their control.” — Naval Ravikant

Ability to Teach and Learn
Having the ability to lift your teammates is invaluable. You might be extremely proficient in X, while your teammate might be experienced in Y. The ability to exchange knowledge is often looked down upon. Great teams put their minds together. Greater problems require great teams.

Photo by Kimberly Farmer on Unsplash

If you want to become a truly great engineer, you should be able to swallow your ego and status. Wise senior engineers will often tell you they learn new things from junior engineers all the time. Junior engineers are eager to prove themselves and learn the latest and coolest programming tooling, only to demonstrate the tools to the team. A wise engineer considers and accepts any information from any source. Leave your dogmas at the door.

Amazing developers who lack team skills stagnate in roles, while perhaps less technically adept devs, who are more personable and more able to sell their ideas, flourish.
Don’t Give Up When Things Get Hard (Be Willing to Put the Hours In)
One day you will face a challenge that you have no business with. It shocks and overwhelms you. You ask yourself “I have to do what?!”. Stay calm, don’t panic. As a software engineer, I can assure you this is all part of the ride. Feeling overwhelmed is actually a good thing, it’s how we evolve. To grow, we have to face new and harder challenges — it’s the only way. When the time comes, don’t be afraid to take the leap forward.

Photo by Kristopher Roller on Unsplash

As with any skill, you have to put in the hours. If it’s worth doing, it’s worth doing great. Don’t just do things for the sake of it, do it because you want to show everyone how great your work is. If you’re asked to do X, do X and add some sugar on top of it. A good way to put the hours in is just simply to build stuff, build anything, just build it. If you lack ideas, here’s a fun list of apps to build:https://medium.com/better-programming/the-secret-to-being-a-top-developer-is-building-things-heres-a-list-of-fun-apps-to-build-aac61ac0736c
Taking Ownership and Beyond
Every executive or manager wants to carve the ownership ideology deep inside every team, for good reason. If workers take ownership and treat their code or products as if it belongs to them personally, they will take special care and consideration.

Photo by ROOM on Unsplash

When working for a small team inside a big company, one can quickly lose the ownership feeling. It’s crucial to treat any codebase as if the next person to deal with the code will be a serial killer who knows where you live. Jokes aside, I think ownership is a powerful concept. If you’re given a task, treat that task as though it serves you directly. In the grand scheme of things, you want to work in a well-known company, that changes the world for the better and leaves a dent in the universe. By taking ownership and responsibility, you’re directly signaling your values and beliefs.

Thanks for reading, I hope you learned something new. Happy coding!
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/