Freeing Julian Assange

The Julian Assange Saga: A Journey of Truth, Controversy, and Injustice

The Beginning: Wikileaks and the Unveiling of Secrets

In 2006, Julian Assange founded WikiLeaks, an online platform dedicated to publishing classified and sensitive documents provided by anonymous sources. The organization's mission was clear: to reveal hidden truths and hold powerful entities accountable. WikiLeaks gained global recognition in 2010 when it released a series of leaks provided by U.S. Army intelligence analyst Chelsea Manning. These included the infamous "Collateral Murder" video, which showed a U.S. helicopter attack in Baghdad that killed several people, including two Reuters journalists.

The Fallout: Global Controversy and Legal Challenges

The publication of these documents ignited a firestorm of controversy. Governments, particularly the United States, condemned WikiLeaks, accusing Assange of endangering lives and national security. Supporters hailed him as a champion of transparency and free speech. As the legal pressure mounted, Assange sought refuge in the Ecuadorian Embassy in London in 2012, fearing extradition to the U.S. on charges of espionage and conspiracy to commit computer intrusion.

The Ecuadorian Embassy Standoff

For nearly seven years, Assange remained in the embassy, living in a small room under constant surveillance. His health deteriorated, and the situation became increasingly untenable. In April 2019, Ecuador revoked his asylum, and British police arrested him. This marked the beginning of a new phase in his legal battles.

Extradition Hearings and Legal Battles

Assange faced extradition to the United States, where he was charged with 18 counts, including conspiring to hack government computers and violating the Espionage Act. The charges carried a potential sentence of up to 175 years in prison. Human rights organizations and press freedom advocates warned that his extradition and prosecution would set a dangerous precedent for journalists worldwide.

A Plea Deal and a Glimmer of Hope

In a surprising turn of events, Assange is set to appear in court in Saipan, a U.S. Pacific territory, at 9 am on Wednesday (23:00 GMT on Tuesday). As part of a plea deal, he will plead guilty to one count of espionage and be sentenced to time served. This deal will finally grant him his freedom after a decade-long ordeal. However, this resolution falls far short of true justice. The immense psychological and physical toll on Assange and the infringement on his personal liberties cannot be undone.

Presidential Pardon: A Final Closure?

There are suggestions that Assange may receive a presidential pardon, which would absolve him of any future legal consequences related to his work with WikiLeaks. While this would provide some measure of relief, it cannot erase the years of suffering and the damage done to his reputation. Moreover, it raises profound questions about the current power structure and the treatment of whistleblowers and truth-tellers.

Reflections on Injustice and Corruption

Assange's journey highlights significant issues within the global justice system and the often-contentious relationship between state power and freedom of the press. His case underscores the need for robust protections for journalists and whistleblowers who expose government wrongdoing. The ordeal also reflects broader concerns about corruption and the manipulation of legal frameworks to suppress dissent and transparency.

Moving Forward

As Julian Assange steps out of the courtroom as a free man, the world watches with bated breath. His release marks the end of a dark chapter, but the struggle for truth and justice continues. The legacy of WikiLeaks and Assange's unwavering commitment to transparency will inspire future generations to challenge authority and uphold the principles of free speech and accountability.

This conclusion, while a relief for Assange and his supporters, serves as a stark reminder of the sacrifices made by those who dare to speak truth to power. It calls for a renewed commitment to protecting the rights of individuals who risk everything to reveal the hidden machinations of the powerful and to ensure that such gross miscarriages of justice are never repeated.

Success as a Senior Developer

What qualities make a senior software developer successful?

Many of them are the same qualities that make anyone successful at work. Here, I break down the general qualities necessary for anyone and then drill down to particulars for software developers. 

General Qualities for Success at Work

1. Presentation and Grooming:

   • Presenting well
   • Dressing appropriately
   • Being well-groomed

2. Behavior and Interaction:

   • Acting appropriately
   • Being polite and friendly
   • Having a sense of humor
   • Genuinely being a 'team player'
   • Practicing cooperative habits
   • Turn-taking
   • Promoting other team members
   • Contributing to the mission
   • Upholding esprit de corps
   • Supporting supervisors and subordinates

3. Professional Attitude:

   • Not necessarily being a superstar
   • Keeping abreast of changes in the zeitgeist and corporate culture
   • Being comfortable in your own skin
   • Being principled and respecting others' convictions

4. Work/Life Balance:

   • Maintaining a reasonable work/life balance
   • Satisfying Maslow's hierarchy of needs
   • Having affiliations outside of work for personal support

Specific Qualities for Successful Senior Software Developers

1. Technical Proficiency:

   • Mastery of relevant programming languages and tools
   • Understanding best practices
   • Keeping up with new technologies and methodologies

2. Experience and Knowledge:

   • Extensive experience in the field
   • Understanding the full software development lifecycle
   • Familiarity with different types of projects and challenges

3. Code Quality and Best Practices:

   • Writing clean, maintainable, and efficient code
   • Following coding standards
   • Utilizing design patterns
   • Conducting thorough code reviews

4. Problem-Solving Skills:

   • Approaching problems methodically
   • Breaking down complex issues into manageable parts
   • Thinking critically about solutions

5. Mentorship and Leadership:

   • Mentoring junior team members
   • Sharing knowledge and helping them grow
   • Inspiring and guiding the team

6. Communication Skills:

   • Communicating clearly and effectively with team members, stakeholders, and clients
   • Explaining complex technical concepts to non-technical people

7. Adaptability and Learning:

   • Staying curious and committed to continuous learning
   • Pursuing formal education, self-study, or experimenting with new technologies

8. Attention to Detail:

   • Preventing bugs and errors through meticulous attention to detail
   • Conducting thorough testing and careful code review
   • Proactively identifying and fixing potential issues

9. Project Management:

   • Understanding project management principles
   • Managing time, resources, and expectations effectively
   • Accurately estimating work and delivering on time

10. Collaboration and Teamwork:

    • Building strong relationships with colleagues
    • Working effectively in a team
    • Understanding team dynamics and being open to feedback

11. User-Centered Design:

    • Keeping the end-user in mind throughout the development process
    • Ensuring the final product is functional and user-friendly

12. Ethical Responsibility:

    • Upholding ethical standards in work
    • Ensuring code and products do no harm
    • Respecting user privacy and security

13. Defensive Development:

    • Developing defensively in terms of team formation, system design, protocols, budgeting, and scheduling
    • Anticipating and addressing potential issues based on Murphy's law
    • Focusing on error prevention, detection, handling, and regression testing

Programming Exceptions Vs Old Rules

This will be objected to and ignored by most, but take it from an old hacker who has production code in place decades after designing, writing, building, testing, and delivering it:

Try/Catch, thrown exceptions, and assert() are things I associate with poorly designed code — code likely to fail in non-trivial production. Avoid these idioms. If possible, avoid languages that support them. Suspect development paradigms that blissfully support these things.

By their nature, ‘exceptions’ are pathological instances of uncaught bugs. The discipline of putting these things in place violates an old rule of thumb as to how code should behave. It is something of a prior commitment to the acceptance of bugs. Bugs are enemy number one. A single defect can ruin an entire system that took man-years to build. A single defect opens security defects that can annihilate systems and cause tragic stress in individuals who, empirically, we know have no effective backups to roll back to. Serious code is serious business. Bugs are No Bueno.

And yeah, these are skewed to procedural rules of thumb. Guess what? It’s because they work. Most all of the code you actually use is built that way. Phone apps (not built that way) need to be updated constantly by mandate from Google and Apple. I still use Microsoft Image Composer, written in C. The binary release I use is, as of 2024, 27 years old. These days, languages and platforms themselves don’t last more than a few years, let alone the things built on them.

A few old rules of thumb:

Single Responsibility Principle: A function should do one thing well.

Single Point of Entry and Exit: A function should have a single point of entry and a single point of exit.

Error Handling: Always check and deal appropriately with return values.

Re-entrancy: All code should be re-entrant. State should never be global.

Murphy’s Law: “Anything that can go wrong will go wrong.”

Keep It Simple, Stupid (KISS): Simplicity should be a key goal in design, and unnecessary complexity should be avoided.

You Aren't Gonna Need It (YAGNI): Don’t add functionality until it is necessary.

Don't Repeat Yourself (DRY): Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Separation of Concerns: Different concerns should be separated to reduce complexity and improve maintainability.

Modularity: Break the code into modules or smaller components that can be developed, tested, and understood independently.

Encapsulation: Encapsulate the details that are likely to change.

Consistency: Follow consistent coding conventions and practices.

Code Readability: Code should be written to be read by humans first and computers second.

Avoid Premature Optimization: Optimize later, focusing first on code correctness and simplicity.

Re: Murphy’s law, “Anything that can go wrong will go wrong” The article on Wikipedia, ironically, gets it wrong. I wrote about it here while writing this response:

Murphy's law is NOT simply an adage

It can be downright scary (a) how much people trust Wikipedia and (b) how unreliable it can be. Looking to find a simple statement of Murphy...

https://blog.bobtrower.com/2024/06/murphys-law-is-not-simply-adage.html

** This applies to code blocks as well.