Self proclaimed “thought leader,” Pat Kelly gives his talk on “thought leadership” at the annual This Is That Talks in Whistler, B.C. In the seminar, Kelly covers: How to talk with your hands, how to get a standing ovation, and how to inspire people by saying nothing at all.
Software engineering as it's taught in universities simply doesn't work. It doesn't produce software systems of high quality, and it doesn't produce them for low cost. Sometimes, even when practiced rigorously, it doesn't produce systems at all. That's odd, because in every other field, the term "engineering" is reserved for methods that work. What then, does real software engineering look like? How can we consistently deliver high-quality systems to our customers and employers in a timely fashion and for a reasonable cost? In this session, we'll discuss where software engineering went wrong, and build the case that disciplined Agile methods, far from being "anti-engineering" (as they are often described), actually represent the best of engineering principles applied to the task of software development.
[...] a book by British sociologist and politician Michael Dunlop Young which was first published in 1958. It describes a dystopian society in a future United Kingdom in which intelligence and merit have become the central tenet of society, replacing previous divisions of social class and creating a society stratified between a merited power-holding elite and a disenfranchised underclass of the less merited. The essay satirised the Tripartite System of education that was being practised at the time.
Benchmarking is the practice of comparing business processes and performance metrics to industry bests and best practices from other companies. Dimensions typically measured are quality, time and cost.
Capability Immaturity Model (CIMM) in software engineering is a parody acronym, a semi-serious effort to provide a contrast to the Capability Maturity Model (CMM). The Capability Maturity Model is a five point scale of capability in an organization, ranging from random processes at level 1 to fully defined, managed and optimized processes at level 5. The ability of an organization to carry out its mission on time and within budget is claimed to improve as the CMM level increases.
Some people enter the technology industry to build newer, more exciting kinds of technology as quickly as possible. My keynote will savage these people and will burn important professional bridges, likely forcing me to join a monastery or another penance-focused organization. In my keynote, I will explain why the proliferation of ubiquitous technology is good in the same sense that ubiquitous Venus weather would be good, i.e., not good at all. Using case studies involving machine learning and other hastily-executed figments of Silicon Valley’s imagination, I will explain why computer security (and larger notions of ethical computing) are difficult to achieve if developers insist on literally not questioning anything that they do since even brief introspection would reduce the frequency of git commits. At some point, my microphone will be cut off, possibly by hotel management, but possibly by myself, because microphones are technology and we need to reclaim the stark purity that emerges from amplifying our voices using rams’ horns and sheets of papyrus rolled into cone shapes. I will explain why papyrus cones are not vulnerable to buffer overflow attacks, and then I will conclude by observing that my new start-up papyr.us is looking for talented full-stack developers who are comfortable executing computational tasks on an abacus or several nearby sticks.
Making career choices can be intimidating and stressful. Perhaps this presentation can help. The tidal forces affecting technology impact our careers as well. If we're not actively managing them, we're leaving decisions to chance (or to others), and may not like the outcomes. This presentation describes a framework I've used over the past few years to evaluate both ongoing job satisfaction as well as new opportunities as they appear. I'm happy with the outcomes I've obtained with it, and have used this same framework when providing advice to others, and it has been well received. Hopefully it can help others as well.
In this presentation we'll will be going over introductions to the various focuses in information security and demoing the most common tools that are used in operational security, both offense and defense. You'll leave with an idea on how to freely obtain and use these tools so that you can have what you need for that first interview: experience and a passion for security. This is a green talk for people who don't have a clue on what offensive and defensive people do operationally, from a tool perspective.
The NICE Framework, NIST Special Publication 800-181, establishes taxonomy and common lexicon that is to be used to describe all cybersecurity work and workers irrespective of where or for whom the work is performed. The NICE Framework is intended to be applied in the public, private, and academic sectors. (USA Focused)
The following is a table of contents for my modern-day book, based off of a talk I wrote in 2016 entitled “Pushing Left, Like a Boss”. It serves as a foundational lesson on what “Application Security” is, and how to get started. I hope you find the series helpful.
So, you think you want to be a penetration tester, or you already are and don't understand what the difference between you and all the other "so called" penetration testers out there. Think you know the difference between a Red Team, Penetration Test and a Vulnerability assessment? Know how to write a report your clients will actually read and understand? Can you leverage the strengths of your team mates to get through tough roadblocks, migrate, pivot, pwn and pillage? No? well this talk is probably for you then! We will go through the fascinating, intense and often crazily boring on-site assessment process. Talk about planning and performing Red Teams, how they are different, and why they can be super effective and have some fun along the way. I'll tell you stories that will melt your face, brain and everything in between. Give you the answers to all of your questions you never knew you had, and probably make you question your life choices. By the end of this session you will be ready to take your next steps into the job you've always wanted, or know deep inside that you should probably look for something else. There will be no judgment or shame, only information, laughter and fun.
This presentation gives the viewer an idea of what it is to be a pentester full-time, what a pentester typically works with, how to learn ethical hacking, and improving your chances of getting a full-time job.
Doug White talks about College options, Certifications, and what you need to do to break into the Cybersec field. How to start and move your career if you want to make a living, legally.
Have you considered a tech career that was "above your pay grade"? What about a dream gig that you have few or - gasp - none of the basic qualifications for? Celeste will give you a few tips on how to identify skill gaps, then learn, network, and otherwise wrangle yourself into a job you wanted but never thought you could apply for, and have a better chance to pass the resume review stage.
SBAR is an acronym for Situation, Background, Assessment, Recommendation; a technique that can be used to facilitate prompt and appropriate communication.
Stock options, RSUs, job offers, and taxes—a detailed reference, including hundreds of resources, explained from the ground up and made to be improved over time.
Goldman Sachs managing director and Law School adjunct professor Jim Donovan shares his insights on the skills necessary to manage and cultivate client relationships. Donovan is responsible for advising many of the largest corporate and individual clients of Goldman Sachs. (University of Virginia School of Law, Nov. 6, 2015)
The Peter principle is a concept in management developed by Laurence J. Peter, which observes that people in a hierarchy tend to rise to their "level of incompetence". In other words, employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another. The concept was enunciated in the 1969 book The Peter Principle by Peter and Raymond Hull.
The Dilbert principle refers to a 1990s theory by Dilbert cartoonist Scott Adams stating that companies tend to systematically promote their least competent employees to management (generally middle management), to limit the amount of damage they are capable of doing.
Pournelle's Iron Law of Bureaucracy states that in any bureaucratic organization there will be two kinds of people":
First, there will be those who are devoted to the goals of the organization. Examples are dedicated classroom teachers in an educational bureaucracy, many of the engineers and launch technicians and scientists at NASA, even some agricultural scientists and advisors in the former Soviet Union collective farming administration.
Secondly, there will be those dedicated to the organization itself. Examples are many of the administrators in the education system, many professors of education, many teachers union officials, much of the NASA headquarters staff, etc.
The Iron Law states that in every case the second group will gain and keep control of the organization. It will write the rules, and control promotions within the organization.
It’s hard to pick a single best work by Joel Spolsky, but if I was forced to, I’d pick The Joel Test. It’s his own, highly irresponsible, sloppy test to rate the quality of software, and when anyone asks me what is wrong with their team I usually start by pointing the questioner at the test. Start here. It’s a test with 12 points and as Joel says, “A score of 12 is perfect, 11 is tolerable, but a 10 or lower and you’ve got serious problems”. More important than the points, his test clearly documents what I consider to be healthy aspects of an engineering team, but there are other points to be made. So it is completely an homage to Joel that I offer The Rands Test.
This is a list of questions which may be interesting to a tech job applicant. The points are not ordered and many may not apply to a given position, or work type. It was started as my personal list of questions, which grew over time to include both things I'd like to see more of and red flags which I'd like to avoid. I've also noticed how few questions were asked by people I interviewed and I think those were missed opportunities.
Interview Questions
4 categories of questions: Connect, Culture, Challenges, Close
How did you come to work here?
What do you love most about working here?
Tell me about the most successful hire and why?
Who didn't succeed as a new hire and why?
Tell me about the company's biggest challenge this year and how will this job help to solve it?
How will I measure my performance so I know I'm having a positive impact?
If there were some skills or experience that you wish I had, what would they be?
We're smart. We're incredibly tech savvy. We can rock some mad OSINT with our Google-Fu. We're 85% +-10% sure which part of the body a hat goes on. We think you can never have enough beard. WE THINK THAT'S ACCEPTABLE. The second in his multi-part series on building social prowess, this talk will focus on the inconvenient truth of your book always, always, always being judged by its cover, and how to deal with that with minimal effort so you can get back to sewing more pockets on your utilikilt. This talk covers both male and female situations, though it is primarily unisex. We'll get you set up with a core wardrobe and hygenic skillset so you'll be able to roll out of bed, spend minimal time "getting ready," rock the dreaded client-facing meeting or industry meetup, and get you back home where you can safely take your pants off.
As the popularity of remote working continues to spread, workers today can collaborate across cities, countries and even multiple time zones. How does this change office dynamics? And how can we make sure that all employees, both at headquarters and at home, feel connected? Matt Mullenweg, cofounder of Wordpress and CEO of Automattic (which has a 100 percent distributed workforce), shares his secrets.
Beginning as a series of posts on the Zapier blog, this book is an ongoing work about our experiences as a remote team, with much of the book written by Zapier CEO Wade Foster along with chapters from our team members and other remote employees. We'll update it periodically so you can learn how our thinking and processes change as we've grown from three to 200+ people and beyond, and we'll keep the older versions of each chapter archived so you can learn with us over time.
Developing and implementing a strategy is the central task of any leader. Richard Rumelt shows that there has been a growing and unfortunate tendency to equate motherhood and apple-pie values and fluffy packages of buzzwords with "strategy."
Worthwhile for the first comment in response to the article: "I don’t see anything “senior” about it, or even “engineer”. Seeing problems and solving them is what everyone does. Documenting the solution is one part of solving a problem. An apprentice carpenter does these things, too, and so does a farmer, and a waiter. Unfortunately, it’s not what most software companies reward, or how they operate. Whenever I did this, my manager, at every software company I’ve worked for, would say: “That’s cool, but you’re supposed to add the FooBar feature, and it needs to be done this Friday. Don’t waste time with reverse-engineering, or documentation. Just add one new field to the protocol somewhere. We can clean it up Later(TM).” This is Conway’s Law at work. What sort of company encourages the creation of two critical components which are completely undocumented? The sort of company which doesn’t reward documentation of critical components. That’s not likely to change because the engineer that created them happened to leave. (It took more time to reverse-engineer the protocol than it would have to document it when the knowledge was fresh.) The PM and QA who allowed this to happen are still there, right? What “Senior Engineer” really means is someone who’s spent enough time in the trenches to have earned a job title that allows them the latitude to make these sorts of improvements, and not have a PM question why they aren’t, instead, doing exactly what they were assigned. Look back at the story. Did the “senior engineer” go through proper channels to schedule a “reverse-engineer and document network protocol” task? No, he clearly didn’t trust that it would happen. Or maybe it was already there, but lowest priority (way below “fix CSS on IE”, of course). What was his actual responsibility that week? The story doesn’t say, but I don’t see any remarks about a PM breathing down his neck asking about the CSS fix he asked for (because that PM is the only user of the system, anywhere, of course, who uses IE and sees that particular bug). Documentation is not on this week’s “Sprint”! The process is fundamentally broken. We hear fables like this about how life would be better if we all did something one way (you’ll get promoted to Senior Engineer!), while in practice we’re punished for doing so."
Attrition.org (http://attrition.org/) is a computer security web site dedicated to the collection, dissemination and distribution of information about the security industry for anyone interested in the subject. They maintain one of the only open and honest grim look at the industry, reminding everyone that we must strive to be better than we have been historically. The crusade to expose industry frauds and inform the public about incorrect information in computer security articles is a primary goal of the site. Previously, Attrition.org maintained the largest catalogs of security advisories, text files, and humorous image galleries. They are also known for maintaining the largest mirror of Web site defacements and the creation of the Data Loss Database (Open Source), which eventually became DatalossDB (http://datalossdb.org/).