• 开源镜像
  • 开源沙龙
  • 媛宝
  • 猿帅
  • 注册
  • 登录
  • 息壤开源生活方式平台
  • 加入我们

开源日报

  • 开源日报第535期:《巡游time awesome-japan-otaku》

    1 9 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《巡游time awesome-japan-otaku》
    今日推荐英文原文:《You Only Need 20 Percent to Become an Effective Developer》

    今日推荐开源项目:《巡游time awesome-japan-otaku》传送门:GitHub链接
    推荐理由:在日本值得去看看的宅文化地点和活动列表。除了人尽皆知的圣地秋叶原和有斯巴达战争之称的 CM 之外,实际上日本还有不少值得一看的地方和活动,在出发之前花心思去搜集情报也是旅行乐趣的一部分——毕竟这世界上的大部分东西隔着屏幕看,和在现实中亲眼见到的感受还是有很大不同的。
    今日推荐英文原文:《You Only Need 20 Percent to Become an Effective Developer》作者:Aphinya Dechalert
    原文链接:https://medium.com/better-programming/you-only-need-20-percent-to-become-an-effective-developer-deb75a9f4915
    推荐理由:二八定律与开发者

    You Only Need 20 Percent to Become an Effective Developer

    The hard part is figuring out the right 20 percent

    Pareto’s Law, also known as the 80/20 rule, has been circulating mainstream Internet for a while now, especially in productivity and motivational circles. The general gist goes, 80% of the output is often produced by 20% of the input.

    The 80/20 rule is applied across multiple disciplines, including, but not limited to, distribution of income, economics, sales, management, athletics, and productivity, to name a few.

    It is a rule that’s often cited and used in business and sports — but what about in programming?

    Software engineering is a massive area that spans numerous physical and digital layers, services, devices, and languages. The novice is often under the impression that you just need to learn a few select things and you’re done.

    Except when it comes to digital technologies, you’re never quite done.

    10% Knowledge

    There are a lot of things to learn when it comes to programming.

    However, if we look at it, there are a lot of similarities across the different languages that are currently in popular usage. Overarching concepts and patterns sit on top and span over different linguistic differences.

    Functional and object-oriented are often the most popular to target if you want to write effective code. Modular patterns and event-driven often come into conversations about how to increase efficiency and effectiveness as developers.

    Then, there are patterns and actions in code that comes up over and over again, regardless of which language you’re dealing with — but you need to know the specifics and finer details of how to implement it for your chosen stack.

    They are things like CRUD patterns, dealing with arrays, transforming data, and passing things between components and classes.

    Sessions, open/close connections to databases, social login API consumptions, and payment gateway integrations are some common requirements for back ends. Routing and modular CSS are important ones for front ends.

    5% Work Smarter Not Harder

    Manual work is the biggest inefficient use of time when it comes to programming. Manual patterns in programming are even worse.

    What exactly are manual patterns?

    One of its official names is an imperative pattern — or a procedure where the program needs to take in that specific order to produce the correct output. In reality, things never appear in the order they need to be 100% of the time.

    Flexible code is not about covering every possible scenario that comes up by coding for all the potential contingencies. It’s about writing your code in a way that only depends on the combination of factors and not the order in which they appear. By doing this, you eliminate a layer of complexity.

    Coding smart is the process of reducing complexity and therefore potential points of failure. In addition to this, the number of lines you need to maintain will also be reduced as a side effect.

    5% Creativity

    Creative code is never recommended — unless you’re doing code poetry, which is something different.

    Programming is not art. Programming is the process of translating business requirements into a digital format. However, the ability to creatively connect your knowledge points together is what makes or breaks your final output.

    More often than not, writing code can be seen as mechanical and emotionless. In a way, it is. The idea of creativity is rooted in passion and imagination.

    However, as Mark Twain once stated:

    “There is no such thing as a new idea. It is impossible. We simply take a lot of old ideas and put them into a sort of mental kaleidoscope. We give them a turn and they make new and curious combinations.

    We keep on turning and making new combinations indefinitely; but they are the same old pieces of colored glass that have been in use through all the ages.”

    Being able to create creative solutions is the ability to connect knowledge points together to produce effective software in the given time.

    80% Making Dots

    “You can’t connect the dots looking forward; you can only connect them looking backwards. So, you have to trust that the dots will somehow connect in your future.” — Steve Jobs,Stanford commencement speech
    The most effective and efficient developers among us seem to be a never-ending pool of knowledge that spans across different domains. They seem to know about everything there is to know. You can talk to them about any topic.

    From the common things we see on our social media feeds to random tidbits of knowledge, like the process of glassmaking.

    They spend their time learning, reading, and consuming things beyond their current domain of knowledge. It’s not just limited to the tech stack they’re required to be experts in.

    The impact of this is that they extend their creative boundaries by having more dots to connect when creative solutions are required.

    Innovation is creating dots of knowledge to make something beyond the edge of knowledge. Image by Aphinya Dechalert.

    Having different domains of knowledge also allows the best among us to create software solutions that are intuitive to the experiences and expectations of different stakeholders.

    This is because the person behind the code is also an active consumer of the thing they’re creating. They are aware of the annoyances and broken bits. This gives a fresh perspective for when a solution is required.

    It All Adds Up to 100%

    20% of actual work determines the effectiveness of the output. However, how you spend the rest of the 80% also matters.

    We don’t really get to see the 80% until it materializes in some form within the 20% equation. This is because every project requires a different cocktail of 20%.

    There is no single combination that works every time — no magical solution to every problem. The mythical unicorn developer is just a developer that knows how to engage the right 20% consistently.

    Knowledge is only the tip of everything. Yes, it does account for a great deal of how sturdy, modular, and flexible to growth your final delivery is.

    The ability to recognize patterns and implement knowledge points are also major factors in being an effective and efficient developer.

    To figure out what the right 20% is for your project, you need the range of knowledge points to pick from. That is why the 80% matters too — and why you should cultivate this as much as you can, in addition to spending your time learning patterns and methods of coding.

    Thank you for reading. ❤

    Aphinya
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 开源日报第534期:《像素动图 pixel-art-react》

    31 8 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《像素动图 pixel-art-react》
    今日推荐英文原文:《Do Happy Software Developers Write Better Code?》

    今日推荐开源项目:《像素动图 pixel-art-react》传送门:GitHub链接
    推荐理由:这个项目可以让你轻松的创作出像素画 gif。只需要自己绘制关键帧,它就能给你一个由 CSS 代码组成的 gif。对于喜欢在页面上摆上各种各样像素画的人来说,这个项目能轻松实现他们各种各样的创意;当然了,用来制作一些生草的沙雕 gif 也一样合适。
    今日推荐英文原文:《Do Happy Software Developers Write Better Code?》作者:Małgorzata Kuś
    原文链接:https://medium.com/better-programming/do-happy-software-developers-write-better-code-5eee72b4b1c2
    推荐理由:情绪与编程效率的关系

    Do Happy Software Developers Write Better Code?

    Does being happy make you better at coding or does coding make you happier?

    TL;DR

    It’s complicated, but there does seem to be some evidence that the more negative a person feels, the better their problem-solving performance is. Feeling bad, however, has a detrimental effect on productivity and motivation, while good emotions push you forward and make you slightly more creative. Way to go? Flow and more research.

    Human Factors

    Let’s dig into more details.

    The room is dim and silent. The person sitting at the desk is only visible because of the faint light given off by a couple of large screens. Half-empty mugs are uninterested witnesses of the creative process. Behold—a programmer at work.

    However magical feats of software programming may seem, especially to a layperson’s eye, programming, just like creative writing, playing chess, or painting, is yet another complex cognitive activity that can be studied by psychology. And there are indeed people who focus their work on what is called human factors in software development: moods, emotions, preferences, and their effects on the quality of devs’ work.

    So what is software engineering to a psychologist? A complex skill that requires two different capabilities: creativity and analytical problem-solving. To be successful and write great code, programmers need to be able both to generate many good ideas and to get to the point—find the solution, or at least one that works.

    So there we have it: Being creative and solving complex problems fast and for good is what will make you a great developer. But are those qualities stable over time? What may improve the results and what has the potential to damage them? Or, as one could ask, do happy cows give more milk? Or are angry programmers the best programmers?

    Effects of Emotional States

    The connection between being happy, angry, or sad (formally speaking: affective states) to one’s ability to solve problems or come up with good ideas has been studied multiple times. It seems reasonably important for workforce performance.

    Unfortunately, the results of studies and large metanalysis are quite unclear. Some studies do find that feeling negative emotions can be linked to improved analytical performance. Others, on the other hand, don’t see that link whatsoever. There is research indicating that happiness correlates positively with creativity on specific tasks. But that’s the outside world. Let’s get back to our dim room and a hooded figure bent over a keyboard.

    I looked into two studies that focus on these aspects of human performance in strict relation to software development. Indeed, a multinational study group found out (based on a relatively small group of CS students) that those programmers who reported feeling more positive emotions were better at generating more ideas and that those ideas tended to be of better quality. In other words, if you’re stuck and feeling low on ideas, watching a happy cat video may not hurt your performance, but provided it makes you happier, it may even improve it. If that’s not useful science, I don’t know what is 😉

    On the other hand, the same study found evidence that negative affect can foster critical and analytical thinking. Those who are feeling blue tend to question ideas and concepts more, doubt the existing solution, and aim straight for the answer. Could pissing off your colleagues every once in a while be good for the company?

    Before we run away to throw things to annoy our coworkers, coding happily in the peace of their open spaces, let’s see another perspective. A differently framed study by the same authors has enumerated many unfavourable effects of negative affect in developers. This time asking them to make their own assessments. So whenever devs are feeling bad at work, they are also affected by:
    • Mental unease or disorder: As in any other human, being subject to negative feelings of panic, self-doubt, and frustration can result in mid- or long-term mental health hazards. We don’t wish that on anybody.
    • Low motivation: Resulting in opting out from new opportunities, passing up on ideas, working slower or not taking up new tasks.
    • Work withdrawal: Avoiding the task in question, taking on other assignments that appear easier or, when taken to the extreme, leaving the company.
    • Low productivity: Resulting in delays in delivering results.
    • Decreased adherence to the process: Cutting corners to just get things done and forget about it. Not checking whether the solution works as intended, not testing, not documenting, you name it. Just shipping the bloody thing and moving on.
    • Low-quality code: That’s not surprising when you look above.
    Are all those things worth the slight increase in problem-solving that was mentioned earlier?

    Because when you look at those who reported positive affect, they also reported opposite tendencies:
    • High cognitive performance: I can do it all! Easy.
    • High motivation: And willpower to continue coding.
    • Higher work engagement and perseverance.
    • Higher creativity (and we remember that it’s particularly important).
    • More strict adherence to processes.
    • Higher productivity and improved workflow.
    As you can see, research is somewhat unprecise when it comes to measuring the effect of affect on software engineering performance. It’s hard to build on such shaky ground, so I’m not going to leave you with a helpful to-do list to make you a better coder. There are other psychological findings out there, however, that may come in handy.

    It Touches Artists and Programmers Alike

    Is happiness even something we should strive for at work? How would we define it, and what emotions would we expect to feel? Even those people who report being content with their job don’t usually mean they spend their whole days giggling, drinking coffee, and playing ping-pong. There is something else that does the trick. And it works also for seemingly different lines of work.

    It’s already anecdotal how programmers need their peace and quiet to really get into the zone. But some time ago, and far away from a tech open space, a Hungarian psychologist noticed how artists get drawn into their work and lose track of time and space. He started researching it and later published a theory about what is now the holy grail of happiness at work: a state of flow.

    Flow is a self-reported state of immersion and focus, resulting from performing complex tasks where the difficulty matches our abilities and challenges are welcome. To experience it, you need to be proficient at what you’re doing and work on a problem that is just the right amount of challenging. What happens then is not pure joy because those in the state of flow are so focused on the job they don’t experience many personal emotions. They are “out there,” immersed in the task and their own competence.

    As we know from the life-long research of M. Csikszentmihalyi, people in the state of flow are indeed as happy as it is possible at work. But that is not all and by far not the only benefit. Research findings by a Harvard professor, Teresa Amabile, showed the positive impact of this state of mind: higher levels of productivity, creativity, and happiness last longer than the experience itself. Reaching the state of flow improved those qualities for research subjects for up to three days.

    The effects of the state of flow are almost like a magical potion that, when drunk once, keeps you going for longer than a full weekend. The potion is just chemicals in your brain, brought to life by achieving a state when your action and awareness are merged, your attention is full, and the flow of time becomes irrelevant.

    So, are those who are happier better at coding than the sad and angry ones? It’s hard to tell. We still don’t know enough about things that improve coding performance, and it could be useful to dig deeper. But those who continue to get better at writing code and are able to get in the zone are truly happy while doing so, and the effects on their creativity and well-being are long-lasting.

    Good for you, happy programmers!

    Sources

    What happens when software developers are (un)happy, Daniel Graziotina, Fabian Fagerholmb, Xiaofeng Wangd, Pekka Abrahamssonhttps://reader.elsevier.com/reader/sd/pii/S0164121218300323?token=A8AB02130AFC82E93BD0CF114EFC8EB8390C11C931172656648485E8F00A211AC80DE75655197416BC5DDB8CAB9D6269

    Happy software developers solve problems better, psychological measurements in empirical software engineering; Daniel Graziotin​, Xiaofeng Wang, Pekka Abrahamssonhttps://peerj.com/articles/289/
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 开源日报第533期:《不是俄罗斯方块 hextris》

    30 8 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《不是俄罗斯方块 hextris》
    今日推荐英文原文:《The Future of PHP》

    今日推荐开源项目:《不是俄罗斯方块 hextris》传送门:GitHub链接
    推荐理由:一个以俄罗斯方块为灵感创作的游戏。众所周知,俄罗斯方块是有列的,需要把方块堆叠到一行来得分,而方块又有各种形状;这个游戏当然也有这些元素——六边形的每个边构成一列,方块的形状则经过调整,得分的条件也改成了三个同色方块相连。像这样将常见的物品分解成细节,改变之后重新合成,创造出新的物品,就是一种创新的来源。
    今日推荐英文原文:《The Future of PHP》作者:Daan
    原文链接:https://medium.com/better-programming/does-php-have-a-future-6756f166ba8
    推荐理由:PHP 是世界上最好的语言(大声)

    The Future of PHP

    Is it a dead programming language?

    PHP has had better days, for sure. But is it really dead?

    On a forums like StackOverflow people are suggesting that PHP is dead. Do they have a valid point, or could it be that they just don’t like PHP?

    Let’s take a look at PHP and see if there is a future for this programming language.

    PHP is Still Dominating the Web

    If you take a simple look at the numbers PHP is definitely not dead. PHP is the most used server-side programming language by far. Approximately 75 percent of all webpages are powered by PHP. Take a look at the graph below and see how far PHP is ahead of its competition in terms of how often it’s used. It is fair to conclude that PHP isn’t dead based on this statistic since 75 percent is far too high number for a dead language!

    Source: w3techs.com

    One of the reasons that PHP is used by so many websites is because WordPress uses PHP. The market share of WordPress is approximately 34 percent of all websites. That’s 75 million websites using WordPress.

    Furthermore, there are some other CMS’s like Drupal (3%) and Joomla(2%) which also have a significant share of the market. And there are some popular shop management systems, like Shopify, which have around 1 percent of the total market share.

    A lot of big content and shop management systems are using PHP, which makes PHP important and relevant.

    Building Websites From Scratch

    I can see the argument about building websites from scratch since a lot of people, who use WordPress for example, don’t know how to code. Making a website in WordPress does not require you to know how to code. A lot of people who have a WordPress website probably don’t even know that it’s powered by PHP. So is PHP still used by people who build websites from scratch?

    PHP was and still is a very popular language. One of the reasons for this is that it’s a really easy programming language to learn. That makes it an excellent language for people new to building websites. PHP can be learned without any prior knowledge. I think it’s fair to say that most web developers that have been around for a while probably started out with PHP, or at least have worked with PHP at some point.

    Programming

    Since PHP has been around since 1994 the language has got a little cluttered over time. There are a lot of ways to build the same functionality and a lot of these ways are pretty hacky. This makes it easier to write bad code in PHP. Obviously, it’s possible to write bad code in any language but PHP makes it a little easier because of the way it has grown.

    PHP has been around so long it also has a lot of old stuff. This makes it easy to get started with PHP, but if you stick to the old solution you end up with suboptimal code that doesn’t follow best practices. And this is something that you should really try to avoid. Not following the best practice is something that will happen when you’re inexperienced with PHP since it is not always clear what the best solution is. This is because there are a lot of ways to solve the same problem. This is one of the reasons why ## PHP is hated by some developers.

    On the other hand, you could argue that most web developers don’t write raw PHP. Most of the times you will be using some sort of framework that does a lot of things for you. A popular PHP framework that is very clean is Laravel. The advantage of working with a framework is that a lot of the dirty work is done under the hood. The framework forces you into writing cleaner code.

    PHP 7

    Since the release of PHP 7 a lot of new features and improvements have been introduced. The two most significant improvements are improved speed and better memory usage. This means that websites that use PHP 7 load faster than websites that use an older version of PHP and can handle more users at the same time.

    Code wise, type declarations and new operators have been introduced. Error handling has also been improved.

    Jobs

    Since 75 percent of the web is powered by PHP there will obviously be a lot of jobs involving some sort of PHP coding. All these websites need to be maintained and there are PHP developers needed for that. The enormous market share of PHP won’t be gone overnight, so jobs involving PHP will be around in the future.

    If you take a look at this link to the jobs section of StackOverflow you will find a lot of jobs that require PHP.

    Conclusion

    Although there is a lot of discussion about the future of PHP, it is clear that PHP does have a future. It is by far the most used programming language for websites.

    PHP has been around for a while now and this is reflected in the code. There’s a lot of old stuff that means the best solution is not always clear. Code wise you could use a framework that does a lot of the dirty work for you and forces you to write cleaner code. However, since the introduction of PHP 7, a lot of things have improved.

    If you want to start a career as a PHP developer you won’t run out of options when it comes to finding a job. There are plenty of jobs involving PHP skills and this will stay the same in the near future.

    So what do you think about PHP? Do you think there is a future for this programming language? Or is it dead?

    Thanks for reading!
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 开源日报第532期:《文字游戏 adarkroom》

    29 8 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《文字游戏 adarkroom》
    今日推荐英文原文:《5 Bad Habits of Absolutely Ineffective Technology Managers》

    今日推荐开源项目:《文字游戏 adarkroom》传送门:GitHub链接
    推荐理由:这个项目是一个可以在浏览器上玩的文字游戏,它只由简单的文字与操作面板组成。这个项目实际上是一个相当好的灵感,有些故事并不需要太多的元素来表现它们,有些时候只使用文字一样可以表达出效果(结合想象补足效果更佳),而比起单纯的文字来说,加上一些可操作元素的简单游戏来讲述一个故事兴许别有一番风味。
    今日推荐英文原文:《5 Bad Habits of Absolutely Ineffective Technology Managers》作者:Ravi Shankar Rajan
    原文链接:https://medium.com/better-programming/5-bad-habits-of-absolutely-ineffective-technology-managers-b395e85ad289
    推荐理由:如何更好的带着手下的人前进

    5 Bad Habits of Absolutely Ineffective Technology Managers

    Bad management is a lot like smoking — it is not ignorance but a bad habit

    Barely a week goes by without at least one article or study bemoaning the things managers don’t know or do. They are the perennial punching bags in any industry, and software is no different. In fact, 90% of programmers have a hate-love-hate (in that order) relationship with their managers. On one hand, they hate the restraints enforced by the manager, and on the other hand, they crib if the manager is not around to hear their woes.

    It is a catch-22 situation even for the best of managers. They strive to make everybody happy, and at the same time, somebody sometime is bound to be unhappy.

    That said, there are no perfect managers but most of us who are managers do like to think we are perfect anyway. I do my best as a technology manager but know that I am not always great.

    You might argue here, “Not everybody is perfect. Everybody can make mistakes. What is the big deal?”

    The big deal is bad habits you pick up as a manager, which causes grief to the team. You may think your imperfections are yours to own, but they negatively affect everyone on your team. Your bad habits are like smoking in front of your team. Everybody passively inhales the toxicity of your actions.

    And the haze of smoke is not only due to the bad habits of the manager. It is also created and sustained by millions of individual behaviors taken, or not taken, again and again — despite their actual, known, and chronicled downsides — by the entire team.

    In short, the entire team suffers. The project suffers. The organization suffers. And here are some of the worst habits you should kick to the curb before it is too late.

    1. Releasing a Product Before It’s Ready

    Your real test as a good technology manager comes under a crisis when you’re under pressure to deliver a product to market before it is ready.

    If your behavior changes during a crisis, then you are not a good manager. For example, if you have enforced the discipline of test-driven development (TDD) in non-crisis times but abandon it during a crisis, then you do not really trust that TDD is helpful. If you enforce great coding practices during normal times and let things go haywire during deadlines, you are doing everybody a great disservice.

    Never neglect the little things. Never skimp on that extra effort, that additional few minutes, that delivery of the very best that you can do. It does not matter what others think; it is of prime importance, however, what you think about you.

    Always remember that cutting corners will haunt you — if not now, later. You usually have one chance to delight a customer, and in the case of a product release that becomes a quality disaster, you have probably lost the customer for life.

    2. Hiring Someone Who Is Not Quite Qualified, but Is Likable

    Hiring a good developer can be a tricky business at times. Sometimes you may have a great developer who is a bit loony, broody, and eccentric at times and not liked much by everybody, but he is competent and does his job well.

    On the other hand, we may have an extremely likable person as a developer who is all fluff but no stuff.

    And instead of hiring the most experienced and talented employees, bad managers often target potential employees who aren’t likely to outshine them or question decisions. By focusing on their own emotional needs rather than the needs of the project when hiring, bad managers sabotage the ability of the project to work effectively. Developers who have substandard skills or training make more mistakes and decrease productivity.

    The rule of thumb is don’t hire a developer who “fits in the culture.” Hire a developer who “fits in the job.” As technology managers, you are not running for a popular vote here. You have a project to complete, and you need the best people.

    3. Avoiding or Postponing the Toughest Activity

    Jez Humble has rightly said, “If it hurts, do it more frequently, and bring the pain forward.”

    Perhaps this above statement is one of the most important principles of successful software delivery.

    Yes, I know, doing the hardest thing first is usually the LAST thing any of us want to do. However, it is a bit like taking off a bandage. We all know that if you try to pull off a bandage slowly, the pain seems worse and lasts longer. So most of us would rather just yank it off and be done with it.

    For example, if integration is a painful phase of your project, do it more frequently in small bits and alleviate the pain. If testing is a painful step in your project, don’t do it at the end. Instead, do it continuously right from Day 1 of your project.

    If application documentation is something that is hated throughout your project, do it as soon as a new feature is incorporated into your project. Make documentation an integral part for signing off on the feature.

    The point is rather than waiting until the last minute with the pressure mounting on you all day, just do it! Wake up in the morning and do hard things first so they are out of the way.

    4. Making Every Decision a Consensus Decision

    “Democracies don’t make great products. You need a competent tyrant.”
    Perhaps this one statement of Jean-Louis Gassée, a former Apple executive, summarizes one of the most important traits every good technology manager should have.

    Consensus decision-making sounds like a way to achieve the best possible outcome from the decisions made at work. If you can bring all team members on board, you will have developed a decision that everyone likes, respects, and supports.

    It is a good theory, but it fails to bring a good outcome most of the times. Taking into account all of the varied sources of information required to prioritize (customer input, technical feasibility, market demands, things that need fixing, and so on) and getting the team to unanimous euphoria may not be practical.

    And you end up agreeing to a middle-of-the-road solution, which may not be the best solution. Nobel Prize winner John Nash Jr. calls this the Nash equilibrium. In this situation, you cannot make any more changes without making a particular team member better off (or worse off). The decision may not be the best solution, but it is the fairest option.

    And a fair decision is often the lowest common denominator agreed upon by the group, one which satisfies the team members but is not optimal for the project.

    Remember, as a technology manager you don’t need consensus, but you do need a decision based on consistent decision criteria, which you can get by taking everybody’s feedback. Incorporate all the feedback and take the decision that is the best tradeoff possible in the scenario.

    5. Poor Communication

    George Bernard Shaw rightly said, “The single biggest problem in communication is the illusion that it has taken place.”

    Communication. It is about honesty. It is about treating people in the organization as deserving to know the facts. You do not try to give them half the story. You do not try to hide the story. You treat them as true equals, and you communicate, and you communicate and communicate.

    If you have important information to share with your boss, colleagues, vendors — even if it is not great news — do not wait. If you put off providing them with actionable information until it is too late to act, then your news will never be well received, whether it is good or bad.

    In almost every conceivable scenario, it is to your advantage to communicate as quickly as possible, allowing everyone involved to understand and digest the information, formulate an appropriate reaction, and respond accordingly. If it is bad news, your early warning just might allow for sufficient planning to minimize the damage.

    Above all, remain professional, polite, direct, and clear — all traits that will move your communication in the right direction during your time at your current place of work.

    As the saying goes, professionalism is not the job you do. It’s how you do the job.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
←上一页
1 … 125 126 127 128 129 … 262
下一页→

Proudly powered by WordPress