今日推荐开源项目：《彩虹猫 css-nyan-cat》
今日推荐英文原文：《The Mentality of a Software Engineer》
今日推荐开源项目：《彩虹猫 css-nyan-cat》传送门：GitHub链接
推荐理由：用纯 CSS 画出一只跑动的彩虹猫来。尽管不能做到 100% 的完全一致，但是已经有了彩虹猫的神态在里面。彩虹猫最初是出自一首歌词极其简单但是却十分洗脑的的歌曲《Nyan cat》，有人将猫与这首歌结合成动画之后才成为了现在广为流传的彩虹猫。如果你做好了被洗脑的准备的话可以试试看去听一听（传送门），如果听不懂也没关系，因为即使说的是猫语，你家的猫也是听不懂的。
今日推荐英文原文：《The Mentality of a Software Engineer》作者：mvndy
原文链接：https://medium.com/@hinchman_amanda/the-mentality-of-a-software-engineer-99fedf5248ee
推荐理由：良好的心态与高等级的技术力一样重要
The Mentality of a Software Engineer
Someone probably told you that you don’t have the ability or the means to solve a problem. Someone probably told you “don’t worry about it”. Someone probably told you you can’t be the engineer you want to be.Like many women in engineering, I got my start in my career by working a job being assigned a lot of menial, repetitive tasks. When there was too much work to handle, I turned towards automation and native desktop development to do the jobs I didn’t want to do. At first, it got me in a lot of trouble. Later on, I was told the problems I want to solve is impossible — and nothing motivates me more than that.
Truth of the matter is, when you’re equipped with the 5 essential principles of being a software engineer, only you can decide to be the engineer you want to be.
1. Don’t present a problem; present a solution.
You see a problem at work. It could be that production support is taking you away from sprint commitments. It could be that creating live demos three times a week is eating up the time you could be doing for your actual client work.A wise engineer once told me “don’t present a problem; present a solution”. It’s okay to identify the problem to your leaders — but if the problem is one you’ve been talking about for while, it might just make more sense to explore what it takes to create that solution. There is even more power to do so when working at a small-to-mid-size company!
Examine the underlying factors and causes, and the role everyone plays in contributing to an issue. Enlist the right people to help solve the issue and get perspective about how certain processes work. Working cross-teams/cross-departments/writing automated solutions can be a lot of work, but it really shows initiative and creates bonds and synergy across the board for the people you work with. Working together to explore and solve pain points creates empathy for your teammates across the board!
2. Don’t ask for permissions to solve problems.
Your DNA test just came back: You don’t need permission to solve the problems you were paid to solve.If your team agrees that it’s okay to spend some time on prototyping, do so in a time-boxed setting. Otherwise, explore the solution on your free time and create an open-source version of the work to add to your Github!
But how can a solution work for an organization if it requires collaboration across different teams or departments? I’ve found that grassroots movements are what works. By the time you propose an official idea in a meeting setting, it’s better to have key players in the room already agreeing with you and in on the idea. Bounce ideas off folks, get their input, and get information on how they approach a problem — teamwork is how grassroots movements become successful!
I’ve definitely made mistakes in the past to propose whole new ideas to a room — without knowing what other’s workloads are, what they’re willing and able to contribute and the context of how other roles might play into a solution, it can feel like you’ve simply added workloads to others without figuring out what’s already being done, or that you’re simply stepping on others toes with duplicate effort.
Take the time to explore possible difficulties and evaluate the amount of workload it might take if a solution requires a team effort. If there’s no team effort required and the solution is dependent on the work you put in, create a prototype of the solution you wish to propose. Being an engineer means you’re meant to solve problems — and it’s not always about code.
3. Have a community — a safe space — where you can share your ideas and grow.
I went from being shut-down daily to stumbling on an exciting and welcoming open-source community that is Kotlin. They didn’t just teach me a new language; they taught me it was okay to ask questions. I progressed from asking the “dumbest” questions to asking questions for things that don’t exist. They helped me push past the limits of the language, push past what I thought were my own limits — this community has been with me every step of the way and in every project I’ve taken on.Take what you learn and make open source versions of those lessons. If you’ve taken ideas and solutions from other open-source projects and articles, give the love back! Are you worried that what you’ve wrote has been written before? Well, that topic has yet to be explained by you! Writing is also important as a develop to help formulate how you express yourself as an engineer, and how you present new ideas to your colleagues, and just another way of giving back to your community.
The local Kotlin community is another micro-community for me. I go to monthly meetups and it’s always great to see folks around the city. I’ve made so many friends here since I’ve moved up with no family here, and I can meet up with any of them for coffee any time to talk about code, jobs, or personal life!
Additionally, local tech communities are how I look for new jobs! Tech groups are a great source for finding out who is working on what and what kind of technology is being used. Job descriptions never quite matches the engineering job, and this is hands down the best way to find capable folks and new teammates for specific projects.
4. Failure is growth.
Fail. Fail a lot. When you’re attempting to solve a new problem, take the time to do you research first. Struggle and flail on your own before asking for help. Getting help is fine and always recommended, but asking for help when you don’t know where to start won’t get you much help, and will fatigue those trying to help you.Struggling and flailing changes the conversation from this:
“How do you [do this problem]?”
To this:
“I can’t figure this out! I have [done this to try and solve the problem], and I hit a wall when […]. I’ve tried […] and […], but these options don’t seem to work. I did notice some interesting behavior doing […], but I’m not sure it makes sense because [of certain assumptions made in research].”
The second question not only gives you a chance to grow, but you’ll get far more specific answers. Asking these kinds of questions shows your mentors that you’ve prepared to use their time wisely and when you’ve put in the work to cover the basics, you leave time for mentors giving you specialized knowledge that is difficult to figure out on your own.
5. Know your worth.
Seriously. Know your worth. Know that failure is a sign of growth, and the sign of a good engineer. If you’re asking questions and it’s never the same question asked previously, you’re in a great place. Your title may not necessarily fit your actual job description, so it’s important to keep track of your successes — literally, a list of accomplishments with numbers to back them. See how you add value to your organization, and what responsibilities you’ve gained over time. Are you reducing time in processes by optimizing through automation? Have you rewritten a feature so that it works faster by x amount of seconds? WRITE IT DOWN.Do you research — check for descriptions/responsibilities of jobs. Talk about salaries with people you feel safe discussing it with.
Having a job in tech is a lot like dating. You may be comfortable where you’re at, but if you’ve grown and do a lot more for your people, are you getting out what you put in? Or are you being convinced that you’re not worth as much as you’ve evaluated yourself? Like dating, if you’re in doubt about whether a company or a team values you, boil it down simply to actions (or inaction).
Conclusion
The essence of engineering is “if you haven’t been told you can’t do it, you probably can”. The caveat here is who tells you you can’t.Being a software engineer is really about having the confidence and grit to solve problems and fail in a safe space with a supportive community. People can tell you what you’re worth and tell you what you can and can’t do, but it’s really you who decides what kind of software engineer you want to be.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
