On the DotDev site there's an article from Sharon Steed with a reminder to the developers out there - it's not all about the code (despite what it may seem like in the job description).

Soft skills get a bad rap; especially in tech. Code has always been king, but software constantly changes. The need to be good communicators and generally pleasant coworkers will always be there. That’s why it’s important to dedicate parts of your day to improving those skills that don’t involve code. No matter how great of a dev you are, you aren’t going to to be nearly as successful if you are difficult to be around. Here are a few soft skills crucial to working in tech.

She covers four major topics around these "soft skills", what they are and what you can do to help improve them:

• Being Accessible
• Solving People Problems
• Keeping Your Ego in Check
• Considering the Big Picture

She ends the post by reminding developers that code is only "one part of the machine" and that by developing soft skills you can much more easily further your career as a developer, regardless of how amazing or clean or manageable your code may be.

Christian Mackerprang has an interesting post to his site sharing some of his thoughts about why terrible code gets written by sane people - developers that know what they're doing but, for other reasons, write code that's a mess of anti-patterns and inconsistency.

What I discovered after some months working there [on a legacy Python project], was that the authors were actually an experienced group of senior developers with good technical skills. What could lead a team of competent developers to produce and actually deliver something like this? What I’ve come up is a list. These are some bad habits that even experienced teams can get into which will severely affect your end product, more than any static code checker or development methodology could rescue it from.

His list of reasons covers six of the reasons he sees for the "good people, bad code" situation happening:

• Giving excessive importance to estimates
• Giving no importance to project knowledge
• Focusing on poor metrics such as “issues closed” or “commits per day”
• Assuming that good process fixes bad people
• Ignoring proven practices such as code reviews and unit testing
• Hiring developers with no “people” skills

For each item in the list he briefly covers why it's a bad thing for your engineering group and references to other sources on good suggestions to fix the situation.

The PHPugly podcast, with hosts Eric Van Johnson, Tom Rideout and John Congdon, has posted their latest episode today, Episode #26 - Difficult People

In this episode they talk about using Satis for hosting Composer dependencies, PHP 7.1 RC1, Atom.io, Qualys SSL labs and more. You can listen to this latest episode either using:

• the in-page audio player or
• over on SoundCloud directly.

If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter for updates when new shows are released.

The SitePoint PHP blog has a new tutorial posted showing you how to set up pagination with jQuery and PHP using a simple Silex-based application.

n this article, we’re going to explain how easy it is to paginate your data set using PHP and AJAX via jQuery. We’re also going to use the Silex framework for simplicity.

The data he's going to paginate through is a list of "people" data with ID, name and age values. He starts by helping you get Silex installed and a new project created. With that in place, he shows how to inject the database connection (PDO) into the application and set up the simple route to output the "people" data back to the waiting Javascript. The route includes a page number value that's used in the LIMIT statement to segment the results into pages. He also includes another route that returns a total count of people records so the pagination knows when to end. With the backend in place, he then moves to the frontend, showing the complete code to get the page records and populate them into the page (via a list).

The SitePoint Web blog has a recent post from Matthew Setter offering some helpful hints on working with other people's code. In it he shares suggestions ranging from the technical out to a bit more "learning oriented" to get up to speed on concepts and techniques.

Dealing with code created by other people is a fundamental skill for a developer. Give it a year and other people’s code could even be your own. Today I’m going to look at some of the best approaches for how to deal with other people’s code, read legacy code, effectively. It’s not an easy topic to cover.

He's broken it down into a list of several different topics, each with their own descriptions and links to tools or reading resources for more information:

• Interact
• Observe
• Run Tests
• Fix Bugs designed for Newcomers
• Find Available Resources
• Use a Good IDE
• Read Books & Blogs
• Contribute to Documentation
• Be Considerate

He puts some good emphasis on that final point, reminding the reader that it's not just years of experience that make for a better developer, it's more about skill.

The /Dev/Hell podcast has posted the latest episode of their show, Episode #42 - Hacking Difficult People. This show features hosts Ed Finkler and Chris Hartjes joind by guest Laura Thomson, a Manager at Mozilla.

For episode 42 we are blessed by the wonderful and talented Laura Thomson, Senior Engineering Manager at Mozilla. Laura drops science on managing engineers, Minimum Viable Bureaucracy, HHVM and Hack, and her mid-Atlantic coast accent. This is a must-listen for folks who manage tech teams.

Some of the topics mentioned in this episode include RCS, "The Tyranny of Structurelessness", the HHVM blog and the CodeIgniter project's search for a new home. You can listen to this episode either through the in-page player or by downloading the mp3.

In a recent post to his site Sherif Ramadan looks at the topic of password hashing and why most developers are (still) doing it wrong. He notes that "fixing the people" and their mindset about hashing/salting is much harder than just fixing the code.

Beyond just writing code I also have to solve some very tough problems on a regular basis. Some of which don’t stem from code at all, but from the people behind the code. Fixing code is easy for me (computers just do what I tell them to do), but fixing people proves to be a lot more challenging. Unfortunately some people are of the mindset that they aren’t wrong simply because they’ve never been proven wrong before. To some people being proven wrong goes beyond just words. Some of us are a lot more stubborn than others and so explaining something may not be enough. This is called the wisdom of humility.

He points out that even those that immediately think "rainbow tables" when they think about md5 hashing are behind the times. Most processing methods, including the use of a GPU, can be used much more effectively and don't require the overhead of the large tables. He illustrates with a "random" md5 generator that outputs around 916 million variations. With a GPU running 4k million per second, this kind of cracking won't take long. He also talks about salts and how they can help the situation - but not just append it, hash with it.

It’s usually the result of several underlying factors that people end up making poor choices about security. Some times it’s due to incompetence. Other time it’s due to politics. Whatever the reasons are they are never excusable, because there are better alternatives out there and it’s not as though they are more difficult or less available than others. So there really are no good reasons [not to do it] here.

In this new post Marco Tabini gives his take on "language haters" and how it's less about the language and more about what you do with it.

The reason why I’m here is that, on occasion, a person decides that it’s time write Yet Another PHP Bashing Post. Typically, this is followed by a bunch of Posts Defending PHP. [...] Saying that PHP is horrible or great is no more useful than saying that a hammer is horrible or great (regardless of the number of claws it comes with). [...] The real question is whether PHP - or any other technology - is good for you.

He goes on to mention current successful projects that use PHP, but focuses on the people and the ideas that made them happen, not the language "behind the scenes". He also comments on what he thinks makes a good programmer (and one that has matured past the "X language is the best!" stance):

And this brings me to the crux of the matter: The trick to being a great programmer is to learn as much as you can about as many programming languages and techniques as you can. Eventually, you’ll learn that any language is excellent at some things, good at others, and a poor choice for many others. It’s all about the context, and finding the right tool for the job.

On PHPMaster.com there's a new post by Michelle Sanver about The PHP People, a.k.a the PHP community, and some of the great resources you can use to get help on a problem or just reach out and meet some other PHP-ers in your area (or at a national conference!)

If you're ever stuck on a problem, Google it and you'll find a swarm of users have most likely experienced the same issue and have already shared their solution. If it's not out there, ask in a public forum and people will help you find the answer. And if you've managed to solve it yourself, then write about it! That way you'll be contributing to helping others the same way others are willing to help you. That's one part of the PHP community that makes it really stand out - people share their knowledge and are more than willing to help others along their journey with PHP.

Some resources/places to meet like-minded developers include:

• StackOverflow
• Conferences like PFCongres 2011 or PHPNW 11
• Groups like PHPWomen or local user groups

The community in PHP is huge and is growing every day, and it's all about sharing. If you see someone in need and you're able to help, offer him guidance. If you see an open-source project that's great; contribute and help it grow.

On the CohereCommunity.com blog has a (slightly older, but still good) post about communities and the "when" and "where" of them happening.

I’m talking about people trends and community and HOW. WE. CONNECT. I decided to start old school stylie, and looked up the word 'community' in the dictionary. [...] So community literally means to give gifts to and among each other. Which in turn means my community is a group of people who welcome and honor my gifts, and from whom I can reasonably expect to receive gifts in return.

They go on to talk about the three key elements any good community relies on - the people that make it up, the places they meet (real or virtual) and the "things" that bring them together.

If I could make a single plea to every researcher, academic, economist and reporter it would be to stop counting us and start communicating with us. Learn more about where, why, and how our communities form, and why they’re so important to us (even when they don’t make us any money).

If you're not already involved in a local user group or haven't attended a conference, it's an experience completely different than sitting behind the keys, hacking day to day. PHP.net has a list of both PHP conferences and upcoming events - find one near you and make plans to attend. You'll be glad you did!